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SUMMARY 


The definition of a microprocessor’s architec- 
ture involves many tradeoff decisions and im- 
pacts in very important ways the speed, effi- 
ciency and reliability of any computer system 
based on that architecture. 


The Motorola M68000 Family of microproces- 
sors implements a clean and powerful 32-bit 
architecture with general purpose registers 
and orthogonal addressing modes. A break 
with full compatibility to older 8-bit architec- 
tures was necessary so that advanced con- 


cepts could be introduced by the all-new 8/16/ 


32-bit M68000 Family. The result was a new 
architecture which encompasses features re- 
quired of today’s system solutions and those 
for the rest of this decade and beyond, with 
complete user object-code compatibility. 


In contrast to M68000 architecture, the iAPX 
286 is weighted down with the instruction set 
of the much older 8086, with all of the cum- 
bersome attributes associated with such an- 
cient chip designs. 


As a result, such crippling concepts as seg- 
mented addressing and special purpose reg- 
isters rule the inflexible philosophy of iAPX 
architecture. These exact their harsh penalties 
in a multitude of ways, including excessive 
object code generation — which causes painful 
complexities in the integration of large, intri- 
cate software systems — and forcing at least 
seven times slower-than-M68000 execution in 
the accessing and addressing of large array 
and data structures. 

The decision to implement direct 16-megabyte 
linear addressing was one of the greatest fac- 


tors in the industry-wide acceptance of the 
M68000 Family. Contrast this to the mere 64K- 
byte segmented accesses of the iAPX 286. This 
forces extra manipulations on programmers, 
who must constantly attempt to contort their 
way around the severe limitations of restrictive 
registers and addressing modes. 


The iAPX 286 does not even support virtual 
memory, but only a virtual segment restart ca- 
pability. Contrast this with the virtual I/O, vir- 
tual machine and virtual window concepts 
available with Motorola’s M68000 architecture. 


The 32-bit architecture of M68000 Family mi- 
croprocessors stands in stark contrast to the 
16-bit segmented 8086/iAPX 286. Remarkable 
differences appear in performance, implemen- 
tations, ease-of-use, code and execution effi- 
ciency between the two architectures when 
they are applied to actual programming 
environments. 


In all important respects, the M68000 Family 
is seen to be far superior to the antiquated 
8086/iIAPX 286 architecture and fulfills the 
more sophisticated needs and requirements of 
today’s demanding software systems and 
methodologies. 


This document details the contrasting M68000 
and 8086/iAPX 286 architectures. 


In the final analysis and selection of a 
microprocessor vendor, you will 
undoubtedly require information beyond 


the scope of this document. Please refer 
to the back cover to locate your closest 
Motorola sales office. 








FORWARD 


The M68000 Family: 
Some Design Philosophies 


Many topics must be considered when an 
Original Equipment Manufacturer (OEM) se- 
lects a microprocessor for a target product. The 
importance of each of these topics varies be- 
tween OEMs, and the evaluation of each is in- 
dividual to each OEM. 


This forward presents a general set of topics 
that are typically evaluated and how the M68000 
Family relates. M68000 and iAPX 286 proces- 
sors’ architectures will then be compared in 
detail. 


In analyzing the suitability of a particular mi- 
croprocessor for use in a product, some of the 
areas of concern that arise are: 


Performance 

Need for product 
Capability 

Effort to design in 
Ease of use 
Reliability 

Future 


There is much to consider in each of these 
areas, spanning both the software and hard- 
ware issues about a microprocessor. But, per- 
haps the most important consideration in 
choosing a microprocessor is the architectural 
philosophy around which the chip was de- 
signed. Almost all of the other considerations 
are heavily influenced by that architecture. 


All of these issues will be examined here, with 
an emphasis on architectural concepts. 


ARCHITECTURE 


There are many different philosophies for com- 
puter architectures; each has its own relative 
merits. In designing a powerful, general- 
purpose microprocessor, a manufacturer must 
choose an architecture that best serves a wide 
variety of applications for a large number of 
customers. Certainly, all applications cannot 
be’ best served by a single processor, but a 


manufacturer must target product design for 
the largest percentage of applications to re- 
main profitable. 


To address the needs of the largest share of 
an open market, a microprocessor’s architec- 
ture must not impose numerous restrictions 
on the user. A general-purpose architecture 
provides maximum flexibility for the user. This 
is the common thread of the M68000 Family 
— power, with flexibility. 


Application. Processors designed with a 
general-purpose architecture can be easily 
used in far more applications than a processor 
which was designed for a particular applica- 
tion. However, general-purpose processors 
will usually not perform as well in a specific 
application as a processor that was specifically 
designed for that particular application. 


For example, a processor designed specifically 
for navigational applications would operate 
quite well in an aircraft guidance system, but 


quite poorly in a word processor. A general- 
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purpose processor would perform reasonably 
well in both applications. 


Instructions. Instructions which can use any 
register that is available relieve the resource 
bottlenecks caused by instructions requiring 
specific registers. A general-purpose architec- 
ture can be adapted to many high-level lan- 
guages, whereas, while a processor which is 
designed for a specific language will execute 
that language extremely well, it will execute 
most others quite poorly. 


For example, a processor designed to run For- 
tran will execute Fortran very well, but not Pas- 
cal. The general-purpose processor will per- 
form reasonably well with both languages. 


Bus Structure. Bus structure should aid, not 
hinder, the hardware designer. It is easier and 
less expensive to build a system if the bus al- 
lows mixing of many memory and peripheral 
speeds and configurations. Special bus con- 
trollers and peripherals only raise the cost of 
the system and restrict flexibility. 


Built-in support for 32 bits is mandatory if pain- 
ful redesigns are to be avoided in the future. 


COMPATIBILITY 


Existing Software. Another architectural con- 
sideration should be compatibility with an ex- 
isting architecture, allowing use of the existing 
software base of that older architecture. This 
very significant factor could sometimes offset 
the costs of developing similar software for the 
new architecture. 


Compromise. However, without quite a bit of 
care and forethought, compatibility with too 
old an architecture can lead to too many com- 
promises being made and subsequent loss of 
the computing power available in modern mi- 
croprocessors. This is especially true when the 
original architecture was not designed to allow 
much room for expansion, or was already an 
extension of another design. Extensions of 
some architectures may compromise perfor- 
mance or ease-of-use unless those extensions 
were planned in the original product. 


Eventually, in order to effectively implement 
all of the new-and-improved as well as tried- 
and-true operations in a microprocessor, com- 
patibility with the older architectures must be 
abandoned. Also, the extent to which code 
compatibility is maintained, short of 100%, can 
degrade the advantage of compatibility and 
place greater burden on the user. 


This desire for compatibility is justifiably ended 
when the advantages of the newer operations 
available in processors with a different archi- 
tecture outweigh the disadvantages of incom- 
patibility with the older architecture. 


As an example: older programs often perform 
functions which are no longer needed, have 
been superceded by faster algorithms, or sim- 
ply have been patched so many times that they 
are much too burdensome to use. These pro- 
grams have become useless as such, and, 
when easily rewritten for a new architecture, 
will always run faster. 


Future. When designing a new architecture for 
a processor, future code compatibility can be 
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“built in.” An architecture must be designed 
with future requirements in mind, allowing for 
those ideas which have not yet come to fruition 
and leaving sufficient room for extention be- 
yond what is possible for the present design. 


Designing an architecture for performance 
higher than what can be realized at present, 
and then adjusting that architecture to today’s 
capabilities, leaves plenty of room for future 
expansion. This allows expansion by design 
rather than by compromise. 


PERFORMANCE 


Data Types. The speed of program execution 
is related to many facets of a microprocessor’s 
architecture. One of these is the applicability 
of the data types offered. 


If a system makes high use of 32-bit data, for 
example, but the microprocessor’s architec- 
ture only has 16-bit registers, then obviously 
unacceptable performance will result. If bit 
manipulations are heavily involved, such as 
with operating system execution decisions, 
then an architecture without bit instructions is 
likely to be awkward and slow at performing 
such functions. 


Register Store Size. A wide register space has 
several very important advantages. Most arith- 
metic results can be completely contained in 
the high-speed registers instead of being 
swapped in and out of auxiliary memories. A 
large register space offers another advantage: 
significant optimizations can be done by high- 
level compilers. 


If an architecture supports only a single reg- 
ister for multiply and divide, think of the dis- 
astrous bottleneck caused by the management 
of values through this one register. 


Address Space Size. High performance sys- 
tems demand quick access to large data stores. 
Modern computer systems must manipulate 
large structures for such things as sorting, 
graphics processing, database searches, and 
heavy number crunching, plus support multi- 
user, multi-tasking operations. 





Any architecture which prohibits or compro- 
mises large data structures cannot run any of 
these applications (and many others) efficiently. 


THE CREATION OF AN ADVANCED 
ARCHITECTURE 


The 16-bit MC68000 microprocessor pioneered 
an entirely new architecture. Much of the ex- 
perience from the MC6800, MC6801, and 
MC6809 microprocessors, many of the ideas 
appreciated by programmers in popular min- 
icomputers, and some innovative current and 
future concepts in computer architectures, all 
culminated in the design of the MC68000’s ar- 
chitecture. Ties to the more primitive architec- 
tures of 8-bit machines were severed in all but 
the most necessary areas — such as the ob- 
vious advantages of already-available 8-bit pe- 
ripherals. This left the computer architects the 
freedom to incorporate modern computer sci- 
ence techniques in the flagship microproces- 
sor of a new family of compatible 8/16/32-bit 
microprocessors: the M68000 Family. 


Architectural Size. An early architectural con- 
cern in the design of the MC68000 micropro- 
cessor was the realization that the 64-kilobyte 
address range of a 16-bit address would not 
be sufficient for a new breed of microproces- 
sor. Though expressing 16-bit addresses in a 
16-bit microprocessor seemed easy and code 
efficient, this small code and data space would 
eventually render the processor useless. 


Various address sizes greater than 16 bits were 
studied. Ways of prefixing a few extra bits to 
the 16-bit address would encumber the pro- 
grammer and/or require the additional bits to 
be carried in the opcode. If additional bits had 
to be maintained, the next logical question was 
how many: 24 or 32? 


It soon became obvious that the next logical 
address size was 32 bits, and the decision was 
made to go ahead and design the address size 
as a 32-bit value with a temporary limit at 24 
bits. This limit was made primarily to make the 
number of pins on the package consistent with 
current packaging technology. 


Linear Addressing. There are many techniques 
of extending an address beyond 16 bits. These 





include: 1) retaining a linear address space; 2) 
paging fixed-size memory blocks; and 3) seg- 
mentation of variably-sized blocks. Paging 
techniques have been used for many years to 
simply extend the address range of proces- 
sors. Segmentation is a little more involved 
and allows more flexibility in the placement of 
the memory blocks. While paging and seg- 
mentation are fairly easy to implement in pro- 
cessor design, their monumental disadvan- 
tages evolve from the fact that they are only 
ways of working around a basic shortcoming 
— the 16-bit address. 


The MC68000 designers realized that although 
32-bit linear addressing required their design 
of more addressing bits than either paging or 
segementation schemes, the approach did not 
impose any artificial boundaries: on the pro- 
grammer and allowed vastly more freedom in 
writing programs. Therefore, the MC68000 was 
designed to support a full 32-bit linear address 
space and not force the programmer to main- 
tain time-consuming paging or segmentation 
registers. 


Data Register Size. With the 32-bit address 
size, it then seemed natural to design the data 
handling capability to 32 bits. This would ease 
the programmer’s job by eliminating discrep- 
ancies between different data and address reg- 
ister sizes. 


Data quantities of 32 bits would also extend 
the architecture a good distance into the future, 
not only by handling the 16-bit needs of the 
present, but also the 32-bit needs to come. 
Again, practical considerations in the pin count 
of the present day dual-in-line packages di- 
rected the present limitation of the external 
data path to 16 bits. Now that additional data 
paths are being added with the Pin Grid Array 
(PGA) package, the M68000 Family micropro- 
cessors allow you to take greater advantage of 
the Family’s 32-bit capability. Bus control cir- 
cuitry allows 32-bit transfers to take place us- 
ing multiple memory accesses. 


General Purpose Registers. General purpose 
registers are placed in processors to provide 
high speed access to commonly used varia- 
bles. Programmers must have total freedom 


in the way those registers are allocated and 
used or else the original intent of the registers 
(high speed access) is defeated. 


If the registers have dedicated uses, and this 
dedication forces the programmer to con- 
stantly swap information in and out of them, 
the data might just as well stay out in memory. 
This emphasizes the need for true general-pur- 
pose registers — those which may be assigned 
at will — to provide real programming efficiency. 


Register Set Size. The MC68000 general pur- 
pose register set consists of eight 32-bit data 
registers in which all types of data can be ma- 
nipulated and eight 32-bit address registers 
where memory pointers may reside. Of these 
sixteen registers, the only dedicated use in- 
volves the processor’s use of one as the stack 
pointer for subroutine and interrupt services. 
Otherwise, any data or address register may 
be used as an operand or as a pointer. 


Thus, the design of M68000 Family micropro- 
cessors’ architecture was finialized to a full 32- 
bit linear addressing range and data handling 
capability, with all registers handling 32-bit 
quantities in an undedicated manner. 


Time has proven the wisdom of those deci- 
sions as the limitations of a 64-kilobyte ad- 
dressing range have caused programmers nu- 
merous headaches as they find that present- 
day data and program sizes easily require 
much more than this range. Additionally, the 
simplicity of the linear address space, without 
architecturally imposed boundaries, has made 
programming the MC68000 — and subsequent 
M68000 Family microprocessors — easy. 


THE BEGINNING OF A FAMILY 


The MC68000 was designed as the beginning 
of a family of high-performance microproces- 
sors. As such, many features were considered 
at length in the design. Many of these, while 
not practical for implementation in the initial 
product, were anticipated in the architecture 
so that they could be incorporated at a later 
date. Also, space is available to allow addi- 
tional enhancements in the future. Because of 
this foresight, the MC68000 is already available 
in a variety of new orientations. 


Family Members At Present. The M68000 Fam- 
ily consists of the original MC68000, and the 
MC68008, the MC68010 and the MC68020. The 
MC68008 is identical to the MC68000 except 
that it has an 8-bit data bus and a 20-bit address 
bus, for use in reduced-cost systems. The 
MC68010 is an enhanced version of the 
MC68000 which supports true virtual memory, 
eliminating the need for the additional proces- 
sors required by previous schemes. The 
MC68020 is a complete 32-bit implementation 
with many new instructions, an automatic co- 
processor interface, and an on-chip instruction 
cache which will allow the attainment of an 8 
million-instructions-per-second execution rate. 


Extensions. The chip implementation of all of 
these processors has proven the advantage of 
designing an architecture for future needs. 
These microprocessors are upward object code 
compatible for all user programs and data. 
Each is a planned upward progression of the 
original MC68000, with the MC68008 providing 
the MC68000 power and versatility for 8-bit 
systems. The extension capabilities of the 
MC68000 were built in; they were not an 
afterthought. 


AN ARCHITECTURAL CONTRAST 


The M68000 Microprocessor Family 
and the 
8086/iAPX 286 


GENERAL FEATURES 


Though a look at the general features of both 
the M68000 Family and the 8086/iAPX 286 fam- 
ily is rather extensive, some of the more vital 
comparisons must be made. 


The MC68000 introduced a totally new archi- 
tecture. It was carefully thought out to aid the 
modern programmer by providing the tools 
with which to write the fastest programs with 
the least amount of effort. The iAPX 286 is an 
outgrowth of the 8086 (which was an out- 
growth of the 8080), essentially providing the 
same operations with some added function- 
ality. That added functionality includes faster 
execution and an on-chip memory manager. 


Register Set Alternatives. The register set of 
a microprocessor sets the theme for the entire 
architecture and reflects the philosophies of 
the instruction set. It is the most frequently 
used area during program execution. Because 
of its frequent use, the register set needs to be 
easily accessable to allow streamlined pro- 
gramming and fast program execution. 


Instructions which require specific registers in 
their operation may be more efficiently en- 
coded (a chip implementation matter), but they 
force the programmer into much more rigid 
register use planning. Instructions which allow 
the selection of any register for use as a con- 
stant, variable, or pointer give the programmer 
the freedom to select the most available or 
appropriate register. 


To make fast on-chip registers easy to use, they 
must be available for use without restriction. 
A truly general-purpose register set allows any 
register to be used for any operand or pointer 
to operands with any data or instruction. 


All M68000 Family microprocessors have 16 


general-purpose registers, each of which can 
contain 32 bits of information. Half of these 
registers are used to hold data, and the rest 
are used as pointers to memory. Within these 
categories, any of the eight registers may be 
used in any instruction which may use a reg- 
ister. No M68000 processor instruction re- 
quires the use of a specific register. Most 
M68000 instructions can use a data register as 
an operand, or an address register to point to 
an operand in memory. The programmer has 
free choice which of the eight data or eight 
address registers to use. 


This means that if variables exist in registers 
DO and D2-D5, the programmer may use D1 or 
D6-D7 for values needed for another operation. 
Both programmers and compilers may more 
easily assign registers to use as they see fit. 


Contrast the general purpose register set to a 
register set which has architecturally-imposed 
registers used for particular operations. 


The problem with dedicated registers can be 
demonstrated with the iAPX 286 and its ances- 
tors. Intel architecture only allows one register, 
the AX register, to be used to perform multi- 
plies and divides. If a desired instruction re- 
quires the use of this register and the AX reg- 
ister has been recently used, the value in AX 
must be saved in memory and a new value 
placed in AX, even if that new value is already 
in an adjacent register, say CX, for example. 
After the desired instruction is executed, al- 
though the result may be needed later, the new 
result will have to be saved, probably in mem- 
ory. Then the old value from register AX must 
be reloaded for use in the next few instructions 
and, finally, the new result will have to be 
brought back in to the processor when it is 
needed. 


This overhead of constantly swapping fre- 
quently used, dedicated registers significantly 
burdens the programmer and slows down pro- 
cessing, especially in compiler-generated code. 
Not only does the iAPX 286 multiply and divide 
require the exclusive use of the AX register, 





but the unsigned multiply and both the signed 
and unsigned divides do not even offer an im- 
mediate addressing mode for the source op- 
erand. Thus, extra instructions and time are 
needed to load yet another register merely to 
hold the source. 


Register Scheme — General Purpose versus 
Dedicated. In a general-purpose register scheme 
with a large number of registers, there will 
most likely be enough register space available 
to perform an instruction series. Let’s say that 
a particular routine needs five 16-bit registers 
to hold data, two source pointers, a destination 
pointer, and two table pointers. Using any 
M68000 microprocessor, five data and five ad- 
dress registers could be used with three of 
each left over. No swapping of registers would 
be necessary. 


The dedicated registers of the iAPX 286 would 
require at least four registers to be swapped 





each time the use was changed, consuming 
valuable execution time and code space as well 
as causing a programming headache. Pro- 
grammers readily say that they can always use 
just one more on-chip register. This empha- 
sizes the fact that the more general register 
space available, the better. 


The M68000 Family's register set has eight 32- 
bit data registers and eight 32-bit address reg- 
isters, as shown in Figure 1. Address register 
A7, although used by the processor as a stack 
pointer for subroutine and exception process- 
ing, is accessed and treated just the same as 
all other address registers. Also, due to its use 
as the stack pointer, a second register A7 exists 
to give distinction between the supervisor (op- 
erating system) stack and the user (application 
programs) stack. There is also a program 
counter and a status register. 


Eight Data 
Registers 


Seven Address 
Registers 


Two Stack 
Pointers 


Program Counter 


Status 
Register 


Figure 1. M68000 Register Set 
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iAPX 286 Register Utilization 


0 


DI: 


7 0 


AX: Multiply, divide, /O, strings, no addresses 
AL: 


Same as AX and translate, decimal arithmetic, 
ASCIl arithmetic 


Translate, base pointer when paired with 
the data segment register. 


Strings, loop counts, no addresses 


Multiply, divide, I/O, no addresses 


Stack, no addressing mode access 


Frame pointer to access stack (when paired 
with the stack segment register) 


Source strings, indexing, addresses with 
the data segment register. 


Destination strings, indexing, addresses 


with extra segment register only. 


7 FLAGS: Must be set before any string operation 


“Eight 16-bit general purpose registers’ — iAPX 286 Data Sheet Claim 





Figure 2. Intel iAPX 286 Register Set 


The iAPX 286 has four 16-bit data registers 
which double as eight 8-bit registers, as shown 
in Figure 2. These registers have special pur- 
poses required by the architecture, as noted. 
Four 16-bit memory pointers are used as index 
pointers and as the stack pointer. Each of these 
registers also has particular requirements when 
used with certain instructions. For instance, the 
stack pointer is the only register which may be 
automatically incremented or decremented 
when data is accessed from it. In use, each of 


these four registers often has a particular data 
register paired with it. 


To extend the addressing range of the iAPX 
286, there are four segment registers: one each 
to point to a 64-kilobyte code, data, stack and 
extra segment. Again, during use, these reg- 
isters are frequently paired with specific mem- 
ory pointers by the architecture. The iAPX 286 
also has a flag, instruction pointer and machine 
status word register. 











Source of the iAPX 286 Register Set Prob- 
lem? — 8086. Part of the problem with the 
iAPX 286 register set stems from its source 
— the 8086. The register set of the 8086 
was based on that of the 8080, which was 
based on the original 8008. The 8080 is a 
second generation 8-bit microprocessor, 
usable but not very advanced from to- 
day’s viewpoint. The concepts it em- 
braced were not so much computer sci- 
ence, but solutions for increasingly 
complex logic functions which were pre- 
viously built in medium scale integration. 
Thus, while these first generation proces- 
sors were useful, most computer archi- 
tects and scientists scoffed at them. 


To design the third generation of micro- 
processors, such as the 8086, around the 
8-bit 8080, might have been justifiable to 
retain some compatibility. However, to 
then extend that primitive architecture yet 
one more time to an advanced 16-bit mi- 
croprocessor, so compromises the archi- 
tecture that the result is not practical. 


This genealogic background of the iAPX 
286 architecture is the underlying reason 
why the future of upgradable products is 
doomed. 





As shown in Figure 2, the right-hand side of 
the iAPX 286 data sheet register set illustration 
provides a list of the types of instructions 
which require that register for the operation. 
This list clearly points to the dedicated purpose 
registers of the iAPX 286. 


Contrast this with the use of any data register 
or address register available in instructions for 
M68000 Family microprocessors. 


M68000 Family processors provide eight ad- 
dress and eight data registers, all of which are 
32-bits long and available for unrestricted al- 
location. The iAPX 286 has complex register 
use restrictions in which each register is forced 
to be dedicated to a selected group of opera- 
tions. Not even a single register is free for the 
programmer to use at will. Segments on the 
iAPX 286 must be overwritten, registers 
’ swapped for proper setup, temporarily saved 


and then restored because of the dedicated 
register scheme. 


Practically any 8086/iAPX 286 code can be ex- 
amined to see the problems which plague a 
programmer using the now-archaic Intel 
architecture. 


For example, let’s take a very primitive string 
search. The EDN magazine benchmark study 
has a very simple string search where a sub- 
routine searches a major string for the match 
of a minor string (Benchmark E). The Motorola 
code for that benchmark uses only four work 
registers (a mere quarter of its register set). 
However, the Intel architecture not only forces 
the use of its entire on-chip register set, but 
also requires that two of the working variables 
used in this short benchmark be saved and 
restored on the stack due to insufficient reg- 
ister work space! (See Appendix C). When triv- 
ial functions cause such complications in an 
architecture, the penalty for something of even 
modest complexity leads to very nasty perfor- 
mance problems and obese code generation. 
It is also interesting to note that the Intel ar- 
chitecture requires 41 lines of code to execute 
this benchmark and the MC68000 only 18 lines. 
Such instances of architectural limitations on 
the 8086/iAPX 286 are the rule rather than the 
exception, and several more examples given 
later will underscore this gross inadequacy. 


Not only does the iAPX 286 severely limit the 
programmer to using only two data segment 
registers, but they interact with the offset reg- 
isters which use them, and often overrides 
must be involved to properly match a segment 
register with its proper offset. This matching 
scheme is shown in Figure 3. It.is hard to imag- 
ine. an assembly language programmer re- 
membering the defaults of which segment reg- 
ister match what base register and what possible 
overrides optionally exist. Even worse, imag- 
ine a compiler writer trying to implement these 
restrictions in a code generator! Performance 
is always going to be harshly limited by all of 
the juggling of registers. This is proven time 
and time again in independent benchmarks 
(Appendix B). 


The iAPX 286 programmer must assure that 
proper segment registers are matched, and 
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Figure 3. iAPX 286 Segment Register Matching Scheme 


this must be managed with only four registers 
which are allowed to hold offset values, each 
of which have additional special purpose de- 
mands made on them. Registers BX, BP, Si, 
and DI are the only offset registers allowed. 
Register BX is heavily used for arithmetic/log- 
ical operations and its contents destroyed 
every time the translate instruction is used. The 
BP register is almost always dedicated as a 
frame pointer, so it is completely unavailable 
for most programs and it usually defaults to 
the stack segment (unless used as a double 
index). 


The Si and DI registers which can be used by 
the programmer are overwritten whenever any 
string operation is executed. The SI and DI reg- 
isters use the DS segment register by default, 
but, during string operations, the DI register 
switches to the ES segment register. The facts 
suggest frequent loading and unloading of 
these four offset registers, coupled with the 
required setup or overriding of the proper seg- 
ment registers, heavily contribute to the poor 
performance of the 8086/iAPX 286 architecture. 
As dramatic proof of this, every Pascal pro- 
gram we have seen has compiled with less 
code generated on Motorola’s Pascal 2.3 com- 
piler compared with Intel’s Pascal X125. (Refer 
to. Appendix A for more details.) 


VIRTUAL MEMORY 


It is imperative that any microprocessor in to- 
day’s world support virtual memory capability. 
Virtual memory allows programs to run in 
what appears to be a large high-speed memory 
address space much larger than the actual 
physical memory present. This is accom- 
plished by the capability of a microprocessor 
to detect access to memory pages which are 
not presently in the available memory pool. 


When a virtual memory system detects such 
a reference, it will, unknown to the program, 
make resident the proper memory page or al- 
locate a new page as required. The program 
then continues, none the wiser. 


Thus, virtual memory support provides four 
valuable attributes: 


1. A program may act as though it has as 
much contiguous memory as it wishes for 
any program or data segment. One ex- 
ample would be for arithmetic arrays 
which may be several megabytes in size. 
Another quite common one is where a 
compiler simply keeps its entire symbol 
table in a memory segment and lets it 
extend without limit as each new symbol 
is entered. This latter capability com- 
pletely obsoletes the burdensome effort 
of creating, processing and managing 
“spill” files on direct access devices. 

2. The programmer need not be aware of 
this virtual memory capability and thus 
need not be concerned with the proces- 
sor’s memory protection mechanism. 

3. The ability to support demand paging. 

4. When a memory access faults, the oper- 
ating system can completely recover and 
continue the program. 


iAPX 286’s Virtual Claims. The iAPX 286 com- 
pletely lacks the first three attributes and only 
partially posesses the fourth. 


First of all, no program on the iAPX 286 can 
ever ignore the crippling 64K segment limits 
imposed by its segmented architecture. There 
is absolutely no practical way around this se- 
rious flaw due to the 16-bit offset limit restric- 
tion. Programmers have no choice but to con- 
fine data structures to within an individual 64K 
data segment. Those that attempt to circum- 
vent that severe limit are punished by handi- 
caps of several times the lines and bytes of 
code required. Worse yet, the execution time 
slows down an order of magnitude because of 
the massive amount of descriptor loading then 
required. (An actual example is given later.) 


The second attribute of true virtual memory is 
that the programmer need have no idea of the 





underlying memory management protection 
mechanism, as the virtual facility operates in 
a totally transparent manner. An MC68010/ 
68020 programmer codes programs without 
any regard for the target system. The program 
will execute properly regardless of whether the 
target system is virtual machine, virtual dy- 
namic paged, virtual segmented, real seg- 
mented, or even has no MMU at all. 


The iAPX 286, however, forces the program- 
mer to tell the memory management unit 
(MMU) via special instructions about each 
memory segment just before it is referenced. 
There is no way out. Only if each segment is 
“banked” or “based” can the data therein be 
used. And, since there are only two segment 
registers which can be used for data (and even 
these are required for special purpose uses, 
such as string instructions), there is a consid- 
erable overhead for the loading and unloading 
of segment descriptors in the iAPX 286 
architecture. 


For example, the EDN sort benchmark time for 
the iAPX 286 just to do descriptor loading is 
far longer than the complete execution time 
for the entire MC68000 benchmark! (30.098 
milliseconds for the iAPX 286 — 12 instructions 
— versus 17.348 milliseconds for the entire 
MC68000 benchmark.) Each descriptor load is 
two microseconds on the iAPX 286. 


Contrast the negative effects of forcing the pro- 
grammer to constantly base segments to the 
total freedom an M68000 programmer has 
with no size restrictions or MMU descriptor 
worries. 


The third attribute of virtual memory is that of 
supporting demand paging. The direction of 
sophisticated microprocessor-based computer 
systems is toward virtual memory configura- 
tions based on demand paged physical mem- 
ory. “Paging” means the subdivision of phys- 
ical memory into equally-sized blocks called 
page frames. This division is invisible to tasks 
running within the system. This is a desirable 
method for memory allocation since entire 
code or data segments do not need to be res- 
ident in physical memory. Only those pages 
currently being used by a task need to be as- 
signed page frames. 


The iAPX 286 segmented approach is entirely 
incapable of supporting a demand page 
environment. 


The term “demand” means that a program 
does not need to specify in advance what areas 
of its local address space it requires. An access 
to an address is interpreted by the system as 
a request to provide that memory. In a demand 
paged system, pages are loaded into page 
frames by the operating system when the pro- 
gram addresses them. 


The iAPX 286 segmented scheme has just the 
reverse philosophy. The program must tell its 
MMU in advance what areas are to be used. 
Only a processor with real virtual memory ca- 
pability, such as the MC68010 or MC68020, can 
provide a demand paging enviroment. The 
iAPX 286 MMU does not allow use of dynamic 
paged memory management, by far the most 
popular mode in use for large sophisticated 
systems. This is another drawback of Intel’s 
design where the programmer is burdened 
with the MMU setup. 


Demand paging allows system programmers 
to choose the page size which is most appro- 
priate to their design. Such pages are usually 
2K or 4K bytes. The iAPX 286, on the other 
hand, forces a complete segment to be made 
resident, even if only a few bytes are required 
by the program in execution. Thus, complete 
segments up to 64K may have to be loaded yet 
most of the memory never referenced. The 
same iAPX 286 system can also suffer from the 
other extreme of a large number of tiny seg- 
ments causing excessive overhead due to the 
loading of segment registers. This happens 
due to the module concept of the iAPX 286 
MMU, because there may be a large number 
of small routines. 


For example, high-level language runtime li- 
braries are typically full of a large number of 
small interdependent modules, and each, when 
called, requires the basing of one or more seg- 
ments on the iAPX 286 MMU. Since segment 
basing requires from two to four microseconds 
depending on memory speed, this quickly 
adds up to a significant portion of the execu- 
tion time accrued by a runtime system. Worse 
is the fact that if many or even all of the rou- 


tines are resident (never causing segment 
faults) the segment load and checking over- 
head is still the same! 


With demand paging there is absolutly no 
overhead for accessing loaded pages since 
there are no MMU setup instructions in the 
code. As can be seen in Appendix B, the iAPX 
286 MMU philosophy causes excessive waste 
in execution time; Intel’s own benchmarks 
prove this to be true. This is only the tip of the 
iceberg, however. Even more severe inefficien- 
cies are presented later in this document. 


As for the fourth attribute of virtual memory, 
~ once an iAPX 286 descriptor fault is detected 
then the operating system may furnish the re- 
quired segment and continue the program un- 
detected. However, the problem here is that 
only descriptor faults are detected AND NOT 
MEMORY FAULTS. 


The following paragraphs discuss the wide va- 
riety of features a true virtual memory oper- 
ating system can provide for its users, none of 
which will work on the iAPX 286. This is be- 
cause the iAPX 286 DOES NOT PROVIDE VIR- 
TUAL MEMORY BUT ONLY VIRTUAL 
SEGMENTS INSTEAD. One massive problem 
with the Intel “solution” is that minor bus prob- 
lems create catastrophic system crashes. If a 
bus error occurs on the iAPX 286, there is no 
action that can be taken other than to 
TERMINATE THE AFFECTED PROGRAM IM- 
MEDIATELY, EVEN IF IT IS THE OPERATING 
SYSTEM. The iAPX 286 will not allow any pro- 
gram hitting a bus fault to be continued. 
System integrity and reliability go down the 
tubes. Unfortunately, fault tolerance is next to 
impossible to provide with Intel’s virtual seg- 
ment memory scheme. 


True Virtual Memory Facilities. True virtual 
memory support provides many other features 
beyond mere page fault recovery. The MC68010 
and MC68020 allow an interrupted bus cycle 
to be either rerun or simulated. This simulation 
allows a new host of features which allow 
pseudo accesses to be granted to tasks or 
programs. 


Since the National 16032 does not support bus 
simulation but only instruction retry, and the 
iAPX 286 does not support virtual memory 
faults at all, only the M68000 Family provides 
for virtual machine and virtual I/O notions. 


Virtual /(O means that an operating system 
may provide a complete set of psuedo (virtual) 
peripherals for its tasks or even another op- 
erating system. Virtual I/O is mandatory for the 
realization of a Virtual Machine, since the entire 
set of physical hardware may have to-be sim- 
ulated—even MMU control registers. Only the 
M68000 Family allows the power of Virtual 
Machine, which means that an M68000 system 
can be built which can properly emulate the 
environment of any other given M68000 system. 


Virtual windows are like virtual I/O except that 
a block of memory is simulated instead of I/O 
control registers. This block of memory is ac- 
tually physically owned by another entity, be 
it a task or another system entirely. 


For example, a simple parameter area can be 
arranged between all tasks of a system such 
that a write into that area by any one task will 
“wake up” all other tasks. The creation of such 
event or semaphore windows allows much 
greater flexibility in the design and use of op- 
erating system primitives. Another example 
would be for the construction of parameter 
windows which pass information to and from 
a data-base system. In this way, virtual con- 
nections can be allocated for given functions 
almost without limit, and with access as easy 
as performing a memory reference. 


More Advantages with Motorola’s True Vir- 
tual Memory. Creative use of the bus error re- 
try facility allows for dramatic advances in fail- 
safe systems, as well. For example, let’s say 
the operating system is updating a system ta- 
ble and a write hard-fails due to a defective 
memory location. Since the operating system 
bus error handler would be given control by 
an M68000 Family processor, it can then copy 
the affected page from the defective memory 
into a new page, while marking the old page 
unusable. The write then could be successfully 
continued and system integrity preserved. 


The iAPX 286 however, would have no alter- 





native but to halt or, at most, run in a crippled 
state with the affected operating system func- 
tion totally disabled. This usually results in a 
complete system stall. 


Since bus reads also can be restarted, this 
means that the M68000 Family provides com- 
plete fail-safe recoverability for any program 
code loaded into the system. Being read-only, 
program code can always be re-loaded from 
its source and the memory fetch attempted 
again. If that still fails, then another memory 
page may be mapped into place and recovery 
made as with the previous example. 


Again, programs on the iAPX 286 would simply 
be terminated without any other recourse. 


The bottom line is that only with Motorola’s 
M68000 Family can you have real mainframe 
performance with real virtual memory and vir- 
tual machine capabilities, fault tolerance, and 
the added bonus of its superior instruction set 
and linear address space. 


DATA TYPES AND OPERATIONS 


The variety of data types that a microprocessor 
can inherently operate on exemplifies its flex- 
ibility. The data types supported by M68000 
processors and the iAPX 286 are shown in Fig- 
ure 4. Generally, the more useful the data 
types, the more universally applicable the 
processor. 


As shown in Figure 4, the M68000 has signif- 
icantly more data type capability than the iAPX 
286. The iAPX 286 needs to perform multiple 
instruction sequences and loops to do what 
native instructions offer on the M68000. The 
iAPX 286 offers no memory-to-memory arith- 
metic capability either. 


32 Bits Since the Beginning. Certainly it has 
been seen over the years that data sizes are 
growing. As 4-bit processors gave way to 8- 
bit, and 8-bit to 16-bit, so 16-bit processors will 
bow to 32-bit processors. The key to each of 
these is the maximum data size that can be 
universally operated on. To be considered an 
“advanced” microprocessor today, a CPU 
should be designed with its operations ex- 
tended all the way to 32-bit data types. This is 





Data Type M68000 iAPX 286 


Bits 

Bytes 

Boolean Bytes 
Strings 

ASCII Arithmetic 
Word Integer 

Long Word Integer 
8-Bit Binary Multiple 





















x* 
x* 

xX 

DIV/MUL only* 

















Precision Register Only 
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* Each of these data types requires exclusive use of the AX 
register. 


Figure 4. Data Types Supported Directly by Instructions 


particularly important to systems which antic- 
ipate expansion in the future, as well as today’s 
high performance machines. The MC68000, in 
its original design, was made to perform arith- 
metic and logical operations on 8-, 16-, and 32- 
bits of data. 


In many ways, 32-bit capability gives the 
M68000 Family twice the capability of other 16- 
bit microprocessors like the iAPX 286. The only 
iAPX 286 instructions which handle 32-bit data 
are multiplication and division. And they are 
forced to use a single register pair (AX, DX)! 
M68000 processors perform these operations 
and many more. A comparison of the 32-bit 
instructions in M68000 Family processors and 
the iAPX 286 is given in Figure 5. 


It is no wonder that Intel consistently avoids 
providing benchmarks with 32-bit arithmetic. 


Bit Manipulation. Individual bit manipulation 
is very important for I/O operations, flag ma- 
nipulations, resource allocation, and a host of 
other applications. Early 8-bit microprocessors 
typically had to perform bit manipulation in 
registers, by using the logical instruction (AND, 
OR, and Exclusive OR) on the appropriate bits. 
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Figure 5. 32-Bit Instruction Set Comparison 


The M68000 Family has four bit manipulation 
instructions that allow the testing, or testing 
and setting, clearing or changing of any bit in 
any data register or memory or I/O location. 
Single bit manipulation in the M68000 is very 
straightforward, easy to remember, and easy 
to use. 


The iAPX 286 follows the 8086’s lead in bit 
manipulation, only providing the ability to test 
individual bits by the primitive ANDing of the 
desired bit in a register after first using another 
instruction just to load it in. A rather complex 
routine would be necessary for an iAPX 286 to 
duplicate an M68000 Family processor’s sim- 
ple bit test and clear (BCLR) instruction. Simple 


bit manipulation operations are requisite in 
modern computer systems. 


Many conditional branches are determined by 
testing bit flags in memory. This is especially 
true of most operating system code, and the 
lack of a bit test instruction on the iAPX 286 
causes significant speed degradation for sys- 
tem routines. 


Register and Addressing Mode Flexibility. The 
flexibility of M68000 Family processors in reg- 
isters and addressing modes is perhaps better 
observed by looking at the operation codes (op 
codes) of the two machines, including the ef- 
fective address fields. An example of the ADD 
instruction for M68000 Family processors and 
the iAPX 286 is illustrated in Figure 6. Note that 
each requires essentially 16 bits for the op- 
code, though the M68000 uses 16 additional 
bits for one indexed addressing mode. There 
are subtle differences in the exact operation of 
each ADD instruction, but the most significant 
can be seen when one looks at the variety of 
options available to each machine’s ADD. 


Each ADD instruction has three general op- 
tions which must be settled to determine the 
exact opcode: direction of operation, data size 
and effective address (EA) calculation. Here is 
where the differences in the two processors 
stand out. There is little discrepancy in the di- 
rection selection either to memory or to a reg- 
ister. However, the M68000 allows not only 
byte and word data sizes like the iAPX 286, but 
also a 32-bit long word operand to be added 
as well as an order of magnitude more mode 
choices. 


The real difference in programming each pro- 
cessor becomes apparent when one inspects 
the various combinations of accessing data 
available, as shown in Figure 7. Here the ad- 
ditional addressing modes as well as the ad- 
ditional registers add up to a real advantage 
with M68000 Family Processors. Totalling all 
of the register combinations that may be in- 
cluded in the address calculation, M68000 pro- 
cessors are by far more flexible, with almost 
7000 different ways of accessing the two dif- 
ferent operands. The iAPX 286 can address 8- 
and 16-bit data in only 1200 ways. The MC68020 
has approximately 10°, or one hundred thou- 














M68000 Family 
Processors Address Modes Data Types 


ADD Dn to EA 
ADD EA to Dn 
ADD EA to An 
ADD Immed to EA 
ADD Quick to EA 


8*(8+8+8+8+8+128+1) 
8*(8+8+8+8+84+128+1+1+16+1) 
8*(8+8+8+8+4+8+128+1+1+16+1) 
8*(8+8+8+8+128+1) 
8*(8+8+8+8+8+4128+1) 


6984 modes to select from (20952 total) 


iAPX 286 Address Modes Data Types 


ADD reg to EA 
ADD EA to reg 
ADD Immed 
ADD to Ax 
INC EA 


8*(4+4+44+44+441)*3 
8*(44+4+44+4+4+1)*3 
(4+44+44+4+4+41)*3 
(44+44+4+44+4+1)*3 
(4444+44+44+4+1)*3 


1134 modes to select from (2394 total) 





Figure 6. Comparative Opcode Example for ADD Instruction 


sand combinations, of addressing modes! Thus 
it has 100 times the options of the iAPX 286. 
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Index deferred with offset 4 
Absolute short N/A 
Absolute long unavailable 
Relative with offset unavailable 
Relative Index with offset unavailable 








Immediate N/A 


* Each access typically requires an implied segment register 
as well. 
** 4 more, if using 8-bit only. 
N/A Not Applicable 


Figure 7. Addressing Combinations Available for 
Accessing Data 


iAPX 286 Just Doesn't Stack Up. Addressing 
modes are very important to a programmer. 
They provide the means for expressing to the 
processor where to find the data. The more 
means to express the location, the better the 
chance the programmer will find just the way 
that is best for each set of circumstances. 


A comparison of the addressing modes avail- 
able in all M68000 Family processors and the 
iAPX 286 is shown in Figure 8. Each processor 
allows direct access to its on-chip registers, 
and has registers that can point to operands 
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in memory. Each chip supports immediate ad- 
dressing for the use of constants. However, 
M68000 Family processors have a pair of ex- 
tremely useful addressing modes — postincre- 
ment and predecrement, which are missing on 
the Intel, Zilog, and National chips. These two 
modes combine to allow the programmer to 
easily: 


1. scan through a sequence of data, 

2. push data onto a programmer-built stack, 
3. pull data from a programmer-built stack, 
4. push data onto a programmer-built queue, 
5. pull data from a programmer-built queue. 


The importance of these two addressing modes 
is that they are available to virtually all instruc- 
tions, and can use any of the eight address 
registers, eliminating the need for specialized 
stack instructions that only work on a dedi- 
cated stack. These addressing modes allow 
any M68000 instruction to operate on an 
M68000’s system stack or on any number of 
stacks the programmer wishes to build. Eight 
of these may be immediately accessible at any 
time. While the M68000 processors are not 
what computer architects call stack machines, 
they are very simply programmed as such by 
always accessing operands on the stack. 


The iAPX 286 has only two stack operations. 
The POP and PUSH operations of the iAPX 286 
place or remove data from the top of the stack 
and they are limited to 16-bit values only. 
These are the only data stack operations avail- 
able, and they operate on one specific stack. 
There is no other simple way of using another 
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000 rrr Dn reg mod=11 
001 rrr An ” " 
010 rrr (An) (SI/DI/BP/BX) mod=00 


-no auto increment-— 
-no auto decrement-— 


011 err (An), An=An-+ incr 
100 rrr (An), An=An-—iner 






















see next (S!/DI/BP/BX) + d8 mod=01 
101 rrr (An) +d16 (SI/DI/BP/BX) + d16 mod=10 
110 rrr (An) + (Xn)+d8 (BX/BP) + (SI/Dl) + d8 mod=01 
(BX/BP) + (SI/Dl) +d16 mod= 10 

111000 absolute16 absolute16 only mod=00 & 
r/m=110 












-no 24-bit absolute !! 

—-no IP relative— 

—no IP relative— 

#|lmmediate special 


111 001 absolute32 
111010 (PC)+d16 
111011 (PC)+(Xn)+d8 
111 100 #\immediate 


Conditional Program Transfers 













8-bit displacement 
—no long jum 


8-bit displacement 
16-bit displacement 


Figure 8. Comparison of Available Addressing Modes 


stack in the iAPX 286. No other instruction will displacement, depending on the addressing 
operate on the SS:SP stack without manual mode. The general difference in these two is 
manipulation. Imagine a compiler which has the 8-bit offset makes slightly more dense 
a parameter stack, operator parsing stack, and code. 


an operation push down queue along with the ; , 
standard system stack executing on an iAPX | M68000 processors allow indexing of 32-bit 
286. This would amount to the simulation of | values, something which is an order of mag- 


three stacks with drastic performance handi- _—*Nitude slower on the iAPX 286. See the para- 
caps and excessive compiler size. graphs on large data structures for a dramatic 

example of how efficiently the M68000 pro- 
M68000 processors take on such implemen- cessors handle 32-bit indexes compared to 
tation requirements with ease, efficiency and what is required on the iAPX 286 due to its 
no overhead. MMU overhead. 


Another problem with stack operations in the The M68000 Family allows any of the eight 


iAPX 286 is that, in order to access any data address registers to be selected in the one-reg- 
that is buried in the stack, a frame pointer must ister-with-offset mode, and any of the sixteen 
be set up. The frame pointer takes up another data and address registers, as well as the eight 
iAPX 286 register (in fact, the most accessible address registers in the two-register-with-off- 
base register), further congesting the register set index mode. This gives a total of 8 and 128 
set. options as opposed to the 4 and 4 options 
available to iAPX 286 programmers — a sig- 
Indexed and Absolute Addressing. Both archi- nificant difference, with less chance of a reg- 
tectures have indexed addressing modes that ister bottleneck with M68000 processors. 


allow the summing of one or two registers with 
an offset. These very powerful addressing iAPX 286 Does Not Offer Absolute Addressing. 


modes are useful for indexing and referencing Due to its forced segmentation, the Intel ar- 

data in complex tables or lists. The iAPX 286 chitecture mandates that all addresses have 

provides for both 8- and 16-bit displacements, two components: a selector and an offset. The 

while M68000 processors allow a 16- or 8-bit supposed code savings generated (which ap- 
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pears only in Intel’s benchmarks and not in- 
dependent benchmarks) are quite insignificant 
to the extra amount of instruction code it takes 
to handle the segments in many operations. 


In fact, to make matters worse, the iAPX 286 
architecture has forced dedication of segment 
registers for certain operations. For example, 
if one wants to move a string from ‘‘HERE” to 
“THERE” one must ensure that the “HERE” 
segment pointer is in one specific segment reg- 
ister (DS) and that the segment pointer for 





“THERE” is in another very specific segment 
register (ES). The previous values in these seg- 
ment registers are lost and must be restored 
as later required. 


The iAPX 286 further compounds the segment 
overhead problem because it must do a com- 
plete segment verification check every time a 
segment register is loaded. To illustrate the 
point, let’s look at a simple memory-to-mem- 
ory move in the MC68000, the MC68020, the 
8086 and the iAPX 286: 


MC68000/MC68010 | MC68020 | 8086 |iAPX 286 


* M68000 MOVE A WORD FROM HERE 
TO THERE 
MOVE.W HERE, THERE 


* jAPX 286/8086 MOVE A WORD FROM 
HERE TO THERE 
LDS 
LES 
MOVS 


SLHEREPTR 
DI,THERE 


As can be seen, both the iAPX 286 and the 8086 
are significantly slower. However, one point to 
mention is the fact that the iAPX 286 is running 
with twice the speed memory as both the 8086 





and MC68000. Since the iAPX 286 time will be 
actually half when equal memory speeds are 
considered, the real results are more like: 


Mcesooo/mceso10 | Mcé68020 iAPX 286 


The surprising conclusion is that segment 
overhead causes substantially more problems 
with the iAPX 286 than with even the 8086. 
Note that the Intel architecture is not 32-bit, 


like M68000 processors, but only 16 bits. Just 
for interest we also give this benchmark, which 
moves a long word: 


MC68000/MC68010 | MC68020 | 8086 |iAPX 286 


* M68000 MOVE A WORD FROM HERE 
TO THERE 
MOVE.L HERE, THERE 


* jAPX 286/8086 MOVE A WORD FROM 
HERE TO THERE 
LDS 
LES 
MOVS 
MOVS 


SILHEREPTR 
DI, THERE 





Again, when when we compare with equal 
memory speeds: 


MC68000/MC68010 MC68020 8086 iAPX 286 


Program Counter Variances. Program counter 
relative addressing makes it easy for the M68000 
Family programmer to write position-inde- 
pendent object code. By being able to refer- 
ence source data, relative to the location of the 
instruction to use the data, one can access data 
that is tabular, and known to be a specified 
distance away. This way,if the instruction is in 
ROM #17/18 and the data is in ROM #21/22 in 
one system, those ROMs may be moved to 
another system and execute identically so long 
as the data ROMs remain 4 chips apart from 
the instruction ROMs. 


On the other hand, the iAPX 286 expressly for- 
bids the moving of ROMs between systems! 
This is because the MMU on the iAPX 286 re- 
quires that all programs contain segment IDs 
which only have meaning to one individual 
operating system running on just a single hard- 
ware system. Thus, yet another drawback to 
Intel’s method of segmented memory man- 
agement appears. This, like many of the others, 
is due to the fact that the programmer has to 
contend with the iAPX 286 MMU directly, 
which leads to static non-changeable segment 
constants directly in object code. 


M68000 Family processors provide two modes 
of program counter relative addressing: one 
with an offset and one using any of the 16 index 
registers plus an offset. These two modes al- 
low the programmer to access data and still 
have the object code relocatable, without 
changing the code. 


The iAPX 286 has no instruction pointer rela- 
tive addressing modes. 


Overall, M68000 Family microprocessors have 
a greater quantity of more flexible and more 
useful addressing modes than the iAPX 286. 
This has the final advantage of making ac- 
cessing data by instructions of M68000 pro- 
cessors more simple, convenient and appli- 


13 


cable, beyond the more fundamental advantage 
of a 32-bit linear address space over the re- 
strictive segmented addressing of the iAPX 
286. 

INSTRUCTION SET 


One of the most important considerations in 
a microprocessor is the instruction set. From 
an inspection of the instruction set, one can 
quickly grasp the functionality of the proces- 
sor. The more functional the instruction set, 
the more useful the processor will be. Data 
types and addressing modes are a significant 
part of the instruction set. The exact operations 
supported in a processor with specific instruc- 
tions give a broader outlook on the capabilities 
of the machine. 


M68000 processors were designed with an en- 
tirely new instruction set. No older micropro- 
cessor was used as a mold from which the 
instructions were chosen. However, all of the 
experience Motorola has had with 8-bit micro- 
processor products, and the experience of the 
designers and users of popular minicompu- 
ters, contributed directly to the concepts and 
philosophies integrated into the M68000 Fam- 
ily’s instruction set. 


The instructions available in M68000 micro- 
processors span many areas of programming, 
from bit manipulation to high-level language 
support. Powerful, yet flexible instructions 
were included which perform data movement, 
bit manipulation, BCD arithmetic, logical func- 
tions, integer arithmetic, shift and rotate op- 
erations, program control, and high-level lan- 
guage and operating system support. 


M68000 Family processors have a complete, 
orthogonal set of instructions that form a core 
of generally useful operations. Special purpose 
operations which would appeal to only a small 
group of users, which have limited utility or 
which aid only one high-level language, were 
avoided in favor of more and flexible general 
operations. 


Instruction execution was designed to be as 
fast as possible, with the speed of execution 
targeted to the frequency of use of each in- 
struction. This was based on in-depth studies 
on the static and dynamic use of instructions. 








Such operations as register data movement 
were streamlined to execute fastest, while ex- 
clusive ORing to memory was given a lower 
priority. This provides the optimum in software 
efficiency with M68000 processors. 


The 8-bit MC68008 shares the identical instruc- 
tion set of the MC68000. The 16-bit virtual 
memory MC68010 has an enhanced MC68000 
instruction set, adding a handful of operations 
that aid the programmer in new areas of mi- 
croprocessing. Also, speed enhancements of 
some of the original instructions have been 
included. The 32-bit MC68020 adds a number 
of new operations to the MC68010 instruction 
repertoire. These instructions broaden the reach 
of M68000 Family instructions even more. Bit- 
field and coprocessor operations are typical of 
these new instructions. 


The instruction set of the iAPX 286 is essen- 
tially that of the earlier 8086, with two major 
additions. Some “new” instructions were added 
which try to duplicate features already present 
on the M68000 Family. Another group of in- 
structions which was added was necessary for 
the control of the memory management 
scheme. No other real operations were added 
to the iAPX 286 beyond the capability of the 
8086. 


The iAPX 286 is an 8086 with a memory man- 
ager on-chip. No more! 


Figure 9 illustrates the new iAPX 286 instruc- 
tions and the M68000 Family instructions that 
they duplicate. Note that the new Intel instruc- 
tions are still limited to 16 bits. 


There are some significant differences in the 
instruction sets of the processors, and many 
of these differences appear in the discussions 
of other facets of them, such as addressing 
modes. Here, some of the more significant dif- 
ferences will be looked at. 


The iAPX 286 retains all of the instructions of 
the 8086. A couple of these were enhanced, 
but most stayed the same. Most of the critical 
shortcomings of the 8086 instruction set remain. 


Stack Operation. As mentioned in the address- 
ing mode discussion, the M68000 Family al- 
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iAPX 286 M68000 Family 










POPA MOVEM —(SP),reg set 
(regs not selectable) (specified registers) 
(stack only) (any addressing mode) 




















PUSHA 
(regs not selectable) 
(stack only) 


PUSH immed 
IMUL immed 
Shifts immed 
Rotates immed 
ENTER 
LEAVE 
BOUND 


MOVEM reg set,(SP) + 
(specified registers) 
(any addressing mode) 


MOVE #immed,(SP) + 
MULS #immed,Dn 

Shifts #ent,Dn 
Rotates #cnt,Dn 
LINK 
UNLINK 
CHECK 













Figure 9. New iAPX 286 Instructions and their M68000 Family 
Equivalents 


lows essentially all data operations to a stack, 
including a simple addressing mode, to access 
data deep in the stack (An+d16). Bytes, words 
or long words of data may be placed on or 
manipulated in a stack. M68000 microproces- 
sors also have a move multiple register 
(MOVEM) instruction which allows either all or 
any subset of the general registers to be moved 
to or from any stack or any data location. This 
is very handy for context switches. 


With two addressing modes (An)+, —(An) of 
M68000 processors, stacks can be built any- 
where. There are nine registers available at any 
one time for use as stack pointers. This gives 
the programmer complete freedom in working 
with stack or queue data structures. 


The iAPX 286 has only the POP and PUSH in- 
structions of its 8086 ancestor with which to 
work on the stack. They will only pull or push 
a 16-bit quantity on the stack. Byte quantities 
must be placed in a register and sign-extended 
before they can be placed on the stack. There 
is no real way of manipulating data on the 
stack. There is an enhancement which allows 
all of the registers to be popped or pushed, 
but, if some subset of the registers is needed, 
many PUSH and POP instructions must be run, 
just as they were on the 8086. 


Because there is only one stack, there is only 
one stack pointer register on the iAPX 286. Due 
to the necessary use of this register for sub- 


routines and interrupts, its integrity must al- 
ways be retained. 


There is no real help given the programmer of 
the iAPX 286 in solving the stack problem. An 
increment (INC) and decrement (DEC) instruc- 
tion can be used to adjust memory pointers, 
but even these have serious shortcomings. 
They may only be incremented or decre- 
mented by a value of one. Should the size of 
the data being used be 16 bits, pointers must 
be incremented twice to step to the next value. 
Rather than two INC instructions being used, 
the usual “add immediate” instruction would 
be better. For source and destination pointers, 
even this must be done twice. 


M68000 processors’ addressing modes take 
care of most stack operations. To ease the 
manual manipulation of pointers and data by 
incrementing, M68000 processors provide the 
“add quick immediate” (ADDQ) and ‘‘subtract 
quick immediate” (SUBQ) instructions. These 
allow the programmer to increment or decre- 
ment any data register, address register or 
memory location by a value from one to eight. 
This gives considerable flexibility and power 
to the programmer when incrementing or dec- 
rementing quantities — far better than the 
iAPX 286. 


Another problem with stack operation on the 
iAPX 286 is the fact that the programmer has 
to use a segment override each and every time 
data is referenced on the stack. This is neces- 
sary because there are no addressing modes 
which address the stack. 


MOVE.L (A3)+ ,(A5) + 
DBEQ D3, MORE 


ADDX.L —(A4), —(A1) 
DBRA D2, MORE 


SBCD —(A5), —(A0) 
DBRA D3, MORE 


MOVE.B (A2,D1),(A1) + 
MOVE.B (A5)+,D1 
DBEQ D6, MORE 


String Manipulation. M68000 microproces- 
sors, with auto increment and auto decrement 
addressing modes, provide complex string 
manipulations with ease. Almost any instruc- 
tion can be used as a primitive in a string op- 
eration. The decrement and branch on condi- 
tion (DBcc) instruction is the key looping 
instruction. When placed at the end of one or 
a series of instructions, it will repeat the series 
until a counter is exhausted or the desired (cc) 
condition is met. 


The DBcc instruction placed with just one other 
instruction, such as the MOVE, allows many 
simple string operations to be formed. Using 
DBcc with a handful of other instructions builds 
extremely powerful and flexible string or other 
repeated functions. Without the auto incre- 
ment and auto decrement addressing modes 
of M68000 processors, these would not be pos- 
sible. Some examples of string operations are 
shown in Figure 10. Notice the varied use of 
registers in the operations. 


In the MC68010, some of these repeated op- 
erations execute even faster. The MC68010 
microprocessor enters a special microcode 
routine when it fetches most single-word op- 
codes followed immediately by a “DBcc” which 
branches back to that opcode. This will latch 
both instructions inside the processor, execut- 
ing them as designed, without further re-fetch- 
ing of opcodes. Only data fetches and writes 
will take place as long as the processor remains 
in the loop. This technique speeds up these 
loops anywhere from 20% to 70%. It essentially 
provides the equivalent of thousands of special 
microcoded string operations. 


block move D3 32-bit words 


sum two multiprecision numbers 


subtract two BCD digit strings 


translate string A [A5] to string 


B [A1] using table [A2] until a 
null value is hit or end [count=D6] 





is found 


Figure 10. M68000 Family String Operations 
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The iAPX 286 has some repeatable instruction 
capability, but, like its forerunner, the 8086, it 
only provides a few “dedicated” string instruc- 
tions. Other or complex string operations rev- 
ert to relatively slow instruction streams. Block 
moves, block fills, string comparisons, string 
scans, and string input and output operations 
are given special instructions. But they use 
dedicated registers and are limited in flexibility. 


Should an iAPX 286 programmer need to per- 
form more complex, yet common, string op- 
erations, the normal instructions must be used 


M68000 
(DBcc following:) 


8086/iAPX 286 
(REP with:) 


Add BCD 

Add binary 
Add with carry 
Logical AND 
Arithmetic shift 


Bit test 

and change 
and clear 
and set 
Bound check* 
Clear 
Compare 
Divide* 
Exclusive OR 
Input 

Link Stack* 
Load element 
Logical Shift 


PLT Uae ee 


Move data 
Move Multiple reg* 


Move Peripheral 
Multiply* 

Negate BCD 
Negate 

Negate with carry 
No Operation 
Logical NOT 
Logical OR 
Output 

Rotate 


Rotate with carry 


Scan 

Subtract BCD 
Subtract binary 
Subt with carry 
Set conditionally* 
Test and set 

Test 

Translate 

Unlink* 





* Note: Limited utility. 


Figure 11. String Operations Contrast 


with a looping control (LOOPxx) instruction. A 
comparison of the iAPX 286 operations which 
duplicate M68000 functions shown previously 
is shown in Figure 11. , 


Branching. Conditional branching in program- 
ming is an all-important concept. With it, the 
program can make decisions based on a set of 
conditions. From those decisions, one of a 
number of actions will subsequently take place. 
This is a fundamental basis of computer pro- 
gramming. The ability of a processor to make 
these decisions, and the flexibility by which it 
can take alternate action, directly influences its 
utility. 


M68000 microprocessors provide both condi- 
tional branching and program jumps. The 
jumps are unconditional and can use any ad- 
dressing mode to describe the target routine. 
Branches in an M68000 processor are condi- 
tional and direct the processor to the next rou- 
tine relative to the location of the present rou- 
tine. Sixteen different conditions may be 
specified as the qualifier to the branch, includ- 
ing: always, greater than, less than, etc. The 
target routine may be specified as being up to 
+127 or —128 bytes or up to + or —32 kil- 
obytes away. This 8- or 16-bit displacement 
gives quite a bit of flexibility to the program- 
mer. The MC68020 also allows a full 32-bit dis- 
placement to the conditional branch instruc- 
tions. This gives the programmer the entire 
address range of an M68000 processor over 
which to conditionally branch (16 million times 
larger than the iAPX 286 branch range). 


The iAPX 286 has a serious shortcoming in 
program control operations. It only allows a 
conditional jump to reach up to +127 or — 128 
bytes away. This short range promises to be 
a constant reminder to the programmer of one 
of the limits of the iAPX 286. To perform any 
significant task, iAPX 286 routines will easily 
go over 50 instructions in length — the range 
of the conditional branch. Multi-level program 
branches will be necessary to compensate for 
this. 


Programmers and compilers generating iAPX 
286 code must constantly handle branch con- 
ditions by branching around a jump instruction 
to get around the small branch range, as 
follows: 


AROUND 
FALSECONDITION 


Jcc 
JMP 
AROUND 


Notice that this forces the loss of position in- 
dependent code, since JMPs allow only ab- 
solute addresses on the iAPX 286. Compilers 
have even further difficulties determining when 
forward branches must generate the two-in- 
struction sequence. 


M68000 processors provide a series of boolean 
byte functions that allow high-level languages 
easy access to the result of boolean expres- 
sions. The Scc instruction allows conditional 
setting of a byte in a register or memory lo- 
cation depending on condition codes. Thus, 
branching decisions can be easily implemented. 


The iAPX 286 has no such feature, and its ab- 
sence of bit manipulation instructions guar- 
antees inefficient branch testing on that part. 


Memory-to-Memory Arithmetic. Memory-to- 
memory arithmetic operations are yet another 
set of instructions on M68000 processors which 
are completely missing on the iAPX 286. Arith- 
metic-intensive programs have a high per- 
centage of memory-to-memory requirements, 
such as when one array of values is added to 
another array. Another use of memory-to- 
memory architecture is for multiple precision 
calculations. M68000 processors allow un- 
bounded restrictions on the data size of ex- 
tended precision operations. For example, a 
20-digit BCD number can easily be subtracted 
from another 20-digit BCD number in either 
memory or registers. 


The iAPX 286, without direct support for such 
things, requires very time-consuming manip- 
ulations since, not only are 32-bit operations 
missing, but all values must be loaded into 
registers and the results stored back. The fol- 
lowing example shows the times for a single 
pass through an extended precision operation. 
The iAPX 286 must use a decrement so as not 
to disturb the carry. The decrement only sub- 
tracts one, so it must be coded twice. Also note 
that the LODS requires both a dedicated source 
index register (SI) and a dedicated segment 
register (DS), whereas any address registers 
may be used on M68000 processors. 


As usual, we not only find that M68000 code 
is shorter and easier to understand, but sig- 
nificantly faster as well. 


The iAPX 286 Single Accumulator. The ancient 
lineage of the iAPX 286 clearly shows up in the 
many operations which can only be performed 
in the AX register. This is a throwback to the 
earliest days of microprocessors, indeed the 
earliest days of computers, when only a single 
accumulator was existent. It was entirely jus- 
tifiable back then to provide one accumulator, 
since the circuitry for just that element made 
up a large portion of the computer and the 
gating required to emulate multiple accumu- 
lators was prohibitive. 


TPeday, however, there is no excuse for such a 
restriction. The iAPX 286 AX register serves as 
a dedicated accumulator for such important 
functions as multiply and divide. Each and 
every multiply and divide must be done only 
in this one 16-bit accumulator. Most of the 
multiplies and divides do not even allow an 
immediate operand. 


M68000 Famil iAPX 286 


ADDX.L 
DBRA 


LOOP -(An),-(Am) 


Dn,LOOP 


32 Cycles per Long Word 


Results in microseconds: 
MC68010 
MC68010 + MMU 
MC68020 + PMMU 


(12.5 MHz) 
(10.0 MHz) 
(16.0 MHz) 


2.56 
3.80 
1.06 
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LODS WORD 


LOOP LOOP 
26 X 2 = 52 Cycles per Long 


iAPX 286 ( 8.0 MHz) 
iAPX 286 (equal speed memories 
200 ns) 


6.50 


9.75 








As if this were not enough, there are a host of 
other functions which also require the dedi- 
cated use of the iAPX 286’s accumulator. All 
I/O operations, string operations, translates, 
and decimal and ASCII arithmetic operations 
must use the same accumulator. Another rea- 
son why the AX accumulator is so overworked 
is that there are some special instruction types 
which work more efficiently with the AX ac- 
cumulator than with the other registers. Com- 
pares, adds, subtracts and logical operations 
have special opcodes for more efficient access 
to the AX accumulator than to the other reg- 
isters. The result of all this is massive 
congestion. 


For example, just to compute a subscript ad- 
dress during a sequence of arithmetic calcu- 
lations means that the intermediate value in 
the AX accumulator must always be saved and 
restored over the subscript calculation. 


In almost every instance, identical programs 
coded on both the 8086/iAPX 286 and M68000 
processors show significantly more lines and 
bytes are required for the Intel processors. This 
is due, in part, to the dedicated register scheme 
of the Intel architecture. 


Benchmarks such as the EDN Quicksort dra- 
matically reveal the differences between the 
stark simplicity of the M68000 code versus the 
undecipherable machinations required by In- 
tel. (See Appendicies D and E.) A single, quick 
glance at the two versions is enough to convert 
the most ardent skeptic. It is obvious that the 
Intel programmers had to have put in several 
times the effort over that required of M68000 
programmers. 


CODE COMPATIBILITY ACROSS A FAMILY 


There is only one real justification for extend- 
ing a processor's architecture far beyond where 
it was originally designed to go, with all of the 
compromises that must be made. That is, if the 
programs written on the original processor 
must also run on the extended processors. 


To do this, the programs must run exactly the 
same. If they do not, then each piece of code 
has to be individually examined to determine 
what to modify so that it will perform the same 
operation. 


This is a significant chore, and can often con- 
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sume more time than would be needed to re- 
write the same routine for another processor. 
If just one condition code operates differently 
for any number of instructions, the task of 
manually verifying all code is required. If se- 
quences of code will not execute the same on 
the upgraded processor, these sequences must 
be found and modified so that they will run. 


Trying to retrofit an existing architecture with 
code-compatible upgrades is rather difficult 
unless the architecture was designed for such 
upgrades. Even then, there is a limit to where 
the compromises made for code compatibility 
become too restrictive to really significantly 
improve the overall utility of the instruction set. 


The best opportunity for code compatible up- 
grades is on products which, in their initial de- 
sign, properly anticipated future needs in en- 
hancements. Such a product will easily adapt 
to the improvements without having to com- 
promise in register selection, addressing ca- 
pability, generality and special conditions. 


M68000 FAMILY COMPATIBILITY 


The M68000 Family of processors started with 
the MC68000. The architecture for the MC68000 
was an original design. Backward compatibility 
to earlier 8-bit Motorola microprocessors was 
traded away for the significantly improved per- 
formance of advanced, general instructions. 
Without being bound by older, more primitive 
register combinations, addressing schemes 
and spaces, and limited philosophies, the de- 
signers of the M68000 Family developed a 
completely new, advanced architecture. This 
architecture was designed for future program- 
ming needs, not the past. 


In designing an architecture for future needs, 
room was left for the enhancements to address 
those needs. Not all operations that might be 
desired could be implemented in a producible 
microprocessor. The fundamental functions 
were included, designed with allowance for 
desirable enhancements which could be im- 
plemented as technology permitted. !nstruc- 
tions were designed so that they were not lim- 
ited in concept to their current form, but could 
be easily enhanced to fulfill the requirements 
of future programmers. 


Instructions in the M68000 Family are in a very 


flexible, fundamental form. To provide more 
specific operations would limit both program- 
mer duties today and the expansion of oper- 
ations later as the needs arise. For instance, 
the M68000 Family does not require specific 
string instructions as its instruction set is so 
flexible, so fast, that it outperforms the special 
purpose instructions that are required of the 
limited 8086/iAPX 286 architecture. Also, 32-bit 
addressing was incorporated into M68000 
Family architecture, even though only 24 bits 
of it are presented in the MC68000. 


Motorola is now seeing the fruits of some of 
its earlier planning in the MC68010 and the 
MC68020 microprocessors and in the wide in- 
dustry acceptance of its M68000 Family. 


As previously mentioned, designing a micro- 
processor to be code compatible with an ear- 
lier processor can be advantageous. However, 
the extent to which the code is compatible be- 
comes extremely important when weighing 
the benefits of such compatibility. If there is 
not 100% compatiblility, or too many restric- 
tions are forced on the programmer to main- 
tain compatibility, then it essentially makes the 
processor less useful than a completely differ- 
ent processor. 


To analyze just how compatible one processor 
is with a previous processor, you must ex- 
amine the differences in the code and its ex- 
ecution. In the analysis, it is important to note 
the impact of the differences on a programmer. 
To require a programmer to search every rou- 
tine and assure that a particular condition code 
is not used after a non-compatible instruction 
is executed is not realistic. 


Application programs are the most likely type 
of programs that will need to be transferred 
from an old processor to a new one. These 
programs typically include the routines that 
perform various tasks essential to the assigned 
job of the processor. They include everything 
from number crunching routines, data move- 
ment and manipulation, and so on. 


Utility and operating system routines are also 
likely to be transported to the new processor. 
Though these types of programs need to be 
compatible, they are also typically subject to 
and candidates for change to run more effi- 
ciently on the new processor. This is because 
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the original equipment manufacturer (OEM) 
frequently includes an operating system in the 
end product, and the operating system is so 
frequently executed. 


An operating system is really overhead as far 
as completing the assigned task is concerned. 
Therefore, the quicker the operating system 
performs its duty, the more efficient the system 
is at handling its designed purpose. By incor- 
porating some of the new features of a new 
processor into an older operating system, ef- 
ficiency is improved. 


MC68000 to MC68008 Compatibility. The 
MC68000 has a 100% code compatible 8-bit 
counterpart, the MC68008. These processors 
share the same instruction set, which is a basis 
for the later microprocessors. All programs 
written for the MC68000 will execute identi- 
cally on the MC68008, and vice-versa. Every 
operation is identical in each processor. 


MC68000 to MC68010 Compatibility. The 
MC68010 is an M68000 Family microprocessor 
which does everything the MC68000 can do, 
and more. In order to put additional features 
in the MC68010, two compromises had to be 
made that could potentially affect the execu- 
tion of supervisor state programs (user pro- 
grams are not affected). Except for these two 
minor differences, all MC68000 code will run 
identically on an MC68010. There are some 
new instructions available on the MC68010, 
which add capabilities that were not on the 
MC68000. 


MC68000 to MC68020 Compatibility. The 
MC68020 microprocessor is an enhancement 
of the MC68010. It contains the instruction set 
of the MC68010 with significant additions. The 
MC68020 also has a co-processor interface and 
an on-chip instruction cache. The MC68020 is 
truly a 32-bit microprocessor with: 


32-bit Arithmetic Units 32-bit Registers 
32-bit Logic Units 32-bit Data Bus 
32-bit Address Bus 32-bit Data Types 


Application Level Object Code Compatibility. 
All MC68000 application (user) level object 
code is guaranteed to be 100% compatible 
when run on the MC68008, MC68010, MC68020 
and all planned future M68000 processors. 
This means that any media containing MC68000 
application code will execute the prescribed 





function on the MC68020 the same as if run on 
the MC68000. 


Other than two minor differences between the 
MC68010 and the MC68000, there are no fur- 
ther deviations from the execution of the orig- 
inal instructions of the MC68000 at the super- 
visor level; only additions. These two changes 
have only minimal impact in all existing 
MC68000 software. 


MC68010 Change 1. The first change was made 
to ease operation of the MC68010 as a virtual 
processor. The last remaining unprivileged in- 
struction (MOVE from SR), which allowed a 
user-level program to view the supervisor-re- 
stricted resources [i.e., supervisor stack pointer, 
and the trace (T) bit supervisor (S) bit, and in- 
terrupt (I2-I9) status bits], was made a privi- 
leged instruction. 


To allow this operation in the MC68010, a move 
from condition code register (MOVE from CCR) 
instruction was added. This instruction may be 
used to replace the MOVE from SR instruction 
in MC68000 code that needs to run at the user 
level in an MC68010, since the T, S, and | bits 
are not to be used. 


Another way of making the MC68000 code run 
with MOVE from SR instructions in the user 
mode is simply to extend the privilege viola- 
tion trap handler program with a small routine. 


MC68010 Change 2. The other condition that 
could vary the execution of MC68000 super- 
visor code on an MC68010 deals with the han- 
dling of exceptions (traps and interrupts). 
While a problem should not arise, some ex- 
ception handlers may perform unusual oper- 
ations which need to be checked. 


The possibility for incompatibility is due to the 
fact that the MC68010 places one additional 
word on the stack. Again, this change does not 
affect user programs. 


Affected supervisor-level programs need only 
have a few instructions changed to run on an 
MC68010. The modification is simply a matter 
of increasing by two the displacement used in 
the addressing mode when accessing the stack 
data beyond the return address from the ex- 
ception routine. 


The two described conditions are the only dif- 
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ferences that could possibly alter the way an 
MC68000 program executes on an MC68010. 
One simple routine added in the operating sys- 
tem will handle the first case, and good pro- 
gramming practices or changing a few loca- 
tions in some operating system routines will 
handle the second case. 


iAPX 286 Compatibility 


The iAPX 286, as an outgrowth of the 8086/ 
8088, is promoted as being upward compatible 
with those two processors. Indeed, it retains 
most of the registers, addressing modes, and 
instructions of the 8086. However, the exact 
functionality of the instructions is not the same 
in some cases. Worse, some of the concepts 
introduced by the native mode of the iAPX 286 
not only make it incompatible with the 8086, 
but, should one use 8086 code in an iAPX 286 
system, those new concepts cannot be used 
without a comprehensive rewrite of the pro- 
grams. Of course, this completely destroys the 
intent of code compatibility. 


Operational Modes. The iAPX 286 has two op- 
erational modes: compatibility or real address 
mode, and the native or protected address 
mode. In the compatibility mode, the iAPX 286 
is designed to run 8086 code exactly, with a 
few new instructions added. The 8086 code 
should run the same (if not faster) with a pos- 
sibility of a difference where the 64K byte seg- 
ment boundary limit is pressed. 


Segment Wrap. In the 8086 it is perfectly legal 
for a word of data or code to be accessed from 
the offset $FFFF, getting the high byte from 
$FFFF and the low byte from $0000 (wrapping 
around in the segment rather than flagging a 
overrun fault). In the iAPX 286, this specific 
access would not be allowed, causing a special 
trap to occur. The occasion for this should be 
infrequent, and a mechanism to correct it is 
provided in the trap. 


Bus Locking. Another possibility for iAPX 286 
and 8086 systems to not run the same is due 
to the automatic assertion of the bus lock sig- 
nal upon execution of the exchange (XCHG) 
instruction in iAPX 286 systems. This could 
possibly cause a system to halt if it were not 
decoded in hardware. In the 8086, the LOCK 


prefix may precede any instruction. In the iAPX 
286, the LOCK instruction is privileged and will 
cause a trap if executed at a lower privilege 
level. The operating system will have to em- 
ulate the desired, bus-locked operation. 


Protected Mode Operation. A significant prob- 
lem with compatibility exists in the iAPX 286 
when it is run in the native, or protected, mode. 
This is the mode that the iAPX 286 is designed 
to run in, affording the user all of the features 
it contains. 


Unfortunately, using most of these new fea- 
tures so erodes the concepts on which the 
original 8086 programs were written that they 
will not run properly without alteration. The 
problem is not that the code sequences will 
not execute, but, by executing as written, they 
will very likely violate the principles of the new 
privilege and protection features. 


Because the 8086 has no concept of execution 
privilege levels, any program written for the 
8086 may have free access of any resource. To 
perform its assigned chore, an application pro- 
gram might read some I/O ports, perform some 
function, and then wish to save the data in a 
file. In a native iAPX 286 system, a special I/O 
handling routine must make all I/O accesses at 
a designated |/O privilege level. The applica- 
tion program running at a lower level would 
massage the data and then an operating sys- 
tem task would store the data on disk at the 
operating system privilege level. 


8086 Application Program Compatibility. How 
much of the original routines could be retained 
in the iAPX 286? The I/O handler would have 
to be rewritten to run at the I/O level within the 
task definition. The disk driver routines, which 
will now be run by the operating system, must 
be rewritten to run at the zero privilege level. 
Perhaps the transfers to the disk I/O port will 
be handled by a separate routine at the I/O 
level. The actual manipulation of the incoming 
data can still be performed at the applications 
program privilege level only after all of the 
program transfers to the file and I/O routines 
have been redirected. 


The end result is that a significant amount of 
work will have to be done to modify even low- 
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level applications programs so that they will 
run on the iAPX 286 in its protected mode. An 
alternative to this would be to run the program 
at a higher privilege level, but to do so would 
completely destroy the system integrity that 
the privilege levels were supposed to bring in. 
Programs designed to run on an 8086 will run 
on an iAPX 286 in the native mode only after 
significant reworking by the programmer. 


Segment Base Address. The fundamental 
change in the utility of the segments in an iAPX 
286 from the 8086 can cause significant prob- 
lems for many routines. In the 8086, the seg- 
ment registers directly established a 20-bit 
base address from which to access code and 
data. This base was exactly predictable to any 
programmer in the 8086. In the iAPX 286, the 
segment registers indirectly specify a 24-bit 
base address. The writer of iAPX 286 code can 
not reliably predict what that base may be be- 
cause the operating system will establish it. 
This is one source of problems with iAPX 286 
code compatibility. 


Because the 8086 has so few and dedicated 
registers, and the general instructions are 
somewhat limited, programmers frequently 
make creative use of the resources they have. 
Unfortunately, when an architecture is ex- 
tended beyond where it was originally des- 
tined, changes can defeat this creativity. This 
is vividly illustrated in some of the Carnegie- 
Mellon benchmarks that Intel programmers 
assembled. 


Carnegie-Mellon Benchmark Code. The Car- 
negie-Mellon benchmark A, an I/O interrupt 
kernal, as coded for the 8086, used the CS seg- 
ment register to locate some counters. While 
this is not a good programming practice, it is 
quite possible in the 8086. Unfortunately, the 
iAPX 286 is more restrictive, and, due to its 
protection mechanisms, will not allow variable 
data to reside within a code segment. Thus, 
this fairly simple routine would not run on an 
iAPX 286. 


In the Carnegie-Mellon benchmark |, a Quick- 
sort routine, Intel programmers once again 
wrote code which will not run on the iAPX 286. 
(See Appendix E.) Here, they used program- 


ming practices which they explicitly character- 
ized as dangerous. They used the DS and ES 
segment registers as base registers to point to 
individual records which were being sorted. 
The resulting code will not run on the iAPX 286 
in the native mode because it can not be pre- 
dicted where the segment registers will be 
pointing. 


The Intel programmers developed the code for 
these algorithms as any programmer would, 
for space savings and speed. It points out one 
of the serious architectural flaws in the 8086/ 
iAPX 286 — the lack of registers (the lack of 
base registers in this particular algorithm). The 
programmer is forced to resort to using seg- 
ment registers for purposes other than what 
they were designed. In the iAPX 286 these re- 
strictions grow tighter, resulting in a violation 
of the purpose of the segment registers in the 
memory management scheme. It also illus- 
trates that the iIAPX 286 has only two data seg- 
ment registers, the DS and ES registers. 


And so, once again, the 8086 and the iAPX 286 
are not code compatible, even for application 
programs. 


Guide for an 8086 Code Writer. From another 
approach, in an Intel-written application paper, 
all of the things are noted that an 8086 code 
writer must be aware of to assure the code will 
run on the iAPX 286 as well. A person can only 
wonder about what precautions will be needed 
for future extentions to the architecture. This 
paper begins, ‘‘Due to the iAPX 286 enhance- 
ments for memory protection and virtual ad- 
dressing, some 8086 programs may not work 
correctly when run on an iAPX 286.” 


Would all this be necessary if the part were 
code compatible? The cautions given are not 
trivial. Some are listed in Figure 12. 


Included in the paper are considerations for 
high-level language compatibility. Many of 
these cautions are required due to the new 
privilege levels introduced by the iAPX 286 and 
the new function of the segment registers. 


However, there are other difficulties. Earlier 
high-level languages allowed any procedure 
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Do not use overlapping segments. 

Do not store temporary values in segment registers. 

Avoid operations which may be restricted by the 
iAPX286 to assure system integrity, low interrupt 
latency, or low bus request latencies (i.e. ... STI, 
CLI, HALT, and I/O instructions). 

Write programs independent of operation changes 
required by protection (e.g., XCHG asserting 
LOCK, different single step priority, POPF and 
IRET not changing the interrupt enable flag or !/O 
privilege level, invisible interrupt table, or RET 
affected by the nested task flag in the flag word.) 

Do not rely on the value pushed onto the stack by 
PUSH SP. 


And for operating system upgrade: 

To use the hardware task switch function or multiple 
address spaces, the scheduler must change. 

Code which accesses task context (e.g., register 
state) must change. 

Code which accesses the interrupt table must 
change.Add pointer validation code to the 
prologue of any procedure expecting pointers 
from less trusted callers. 

Structure the operating system to use the iAPX286 
privilege hierarchy. 

Validate pointers from all callers. 


Figure 12. iAPX 286 Programming Guidelines for 8086 
Compatibility (Abridged) 





to be an interrupt procedure. In the iAPX 286, 
no user level program may access the interrupt 
table and therefore it will not load properly. 
Pointer arithmetic in PL/M is common with all 
of the segment registers, offsets and address- 
ing mode rules. Few pointer arithmetic oper- 
ations are compatible between the 8086 and 
iAPX 286. 


Operating System Compatibility. Operating 
system compatibility between the 8086 and the 
iAPX 286 is almost non-existent. 


With the exception of running in the compat- 
ibility mode, with almost none of the new fea- 
tures of the iAPX 286, every 8086 operating 
system will have to be entirely rewritten to be 
used on the iAPX 286. The new privilege levels 
of the iAPX 286 will have to be assigned and 
handled by the operating system and each ap- 
plication program. To prevent invalid pointers 
from being passed to the operating system by 
lower level programs, the operating system 
must verify that any pointer passed is valid. 
Any code which accesses any of the vectors 
for interrupts must be changed, since these 
vectors can only be accessed by the operating 
system. 


These are just a few of the changes that must 
take place in an 8086 operating system for it 
to run on the iAPX 286. As a general rule, a 
totally new operating system will have to be 
written for the iAPX 286. 


Additionally, most application level programs 
will have to be rewritten to protect the various 
operating system and |/O operations to their 
proper privilege level. 


Future Operating System Compatibility. To 
make matters even worse, information re- 
leased by Intel indicates that yet another com- 
plete rewrite of major portions of iAPX 286 
operating systems will be required to move up 
to the iAPX 386. This is because the iAPX 386 
will handle segment faults in an entirely dif- 
ferent manner, in that segments will not be 
allowed to be treated as complete entities for 
residency decisions. Therefore, the operation 
of loading a segment register will no longer be 
sufficient to indicate what working set of mem- 
ory needs to be made resident. As a result, the 
iAPX 286 methods of main storage manage- 
ment will no longer be appropriate. 


Summary. All in all, the iAPX 286 is a micro- 
processor which does use the same instruc- 
tions as the 8086. It also has a few new instruc- 
tions. But it has many very new concepts which 
need to be incorporated into the existing soft- 
ware. Including these new concepts into old 
programs is a major undertaking. 


Having had no foresight as to the future growth 
of the 8086 family, programmers writing 8086 
code had no reason to allow for such devel- 
opments as privilege levels, segment integrity, 
memory management, and even operating 
system isolation. Therefore, when a new mi- 
croprocessor demands that these concepts be- 
come part of the original code, a significant 
burden is placed on the programmer who must 
upgrade it. 


Failure to make the required changes nullifies 
any benefit of moving to the new part. 


PRIVILEGE LEVEL PROTECTION 


The Z8000 and the MC68000 were the first to 
introduce the concept of privilege to micropro- 
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cessors. The MC68000 has two privilege levels: 
supervisor and user. Operating system func- 
tions typically take place at the supervisor 
level, while application programs typically ex- 
ecute at the user level. The supervisor level 
has access to all of the resources of M68000 
processors, and typically all external re- 
sources. The user typically has access to al- 
most all of the resources on an M68000 pro- 
cessor but has restricted access to external 
resources such as memory and |/O. 


The distinction of privilege allows the operat- 
ing system to keep control of all processor and 
even external functions, while protecting itself 
and other code, data and users from the care- 
less activities of a poorly written or unfriendly 
application or user program. The MC68010 has 
even gone one step farther in this privilege 
scheme to secure the supervisor resources 
from even being seen by the user. This facility 
permits the MC68010 and the MC68020 to op- 
erate as a virtual processors. 


The two levels of privilege in M68000 Family 
processors are more than sufficient for provid- 
ing security to an advanced computer system. 
All operating system functions and I/O func- 
tions can easily be implemented in a secure 
manner, without burdening the programmer 
with needless overhead. Various automatic 
and explicit traps give control to the supervisor 
each time the user attempts a questionable 
operation. Notification of improper off-chip 
accesses is simply enacted with either an in- 
terrupt or the unique bus error (BERR) signal. 


The iAPX 286 implements a four-level ring priv- 
ilege structure. It is suggested that application 
programs run at the lowest level (level 3), while 
the operating system maintains the highest 
level (level 0), much the same as on an M68000 
processor. A floating !/O privilege level lets 1/0 
operations take place at any level the operating 
system assigns. It is suggested by the manu- 
facturer that the operating system be segre- 
gated throughout the three highest privilege 
levels based on the significance of each task. 


Switching between programs running at dif- 
ferent privilege levels is effected through com- 
plex gates which are designed to assure the 


security of the iAPX 286 system. Hardware as- 
sures that each privilege level may have its 
own set of registers and processor resources. 
Violation of certain rules forces traps up to the 
controlling operating system. 


The most important thing to be said for the 
iAPX 286 ring architecture is that you have no 
choice but to implement the ring mechanism 
whether you like it or not. 


Even worse, you must accept the segment 
hangups which go along with the rest of the 
architecture. There are some system imple- 
menters who prefer hierarchical levels in their 
architecture, though the vast majority do not. 
The Intel philosophy is one of “take-it-or-leave- 
it.” You use the iAPX 286 definition of a ring 
architecture or you do not use memory man- 
agement at all. 


Motorola does not force any concept of mem- 
ory management. You can use demand pag- 
ing, demand segments, virtual versions of 
each of these or no memory management at 
all. And the best news is that absolutely NO 
progamming changes are required by user 
mode programs to implement or change over 
from one to another, unlike the iAPX 286, 
where absolutely all programs must have 
MMU segment loading operations. 


The MC68020 adds the concept of multiple ac- 
cess levels to the M68000 Family. The access 
concept not only provides automatic module 
connection but also the expansion of up to 256 
hierarchical levels without the cumbersome 
segment limitations forced by the iAPX 286. 


The hierarchical levels are a superset of ring 
architecture with much more flexibility. For 
example, finer gradations are supported which 
allow concepts such as data abstraction to be 
supported. The end result is that a system de- 
signer can, with the MC68020, choose almost 
any type of memory management classifica- 
tion and, due to the flexible nature of the Mo- 
torola architecture, implement specific cus- 
tomizations as desired. For example, a classical 
ring structure can be developed with ring ob- 
jects of up to 4 billion bytes in size instead of 
the restrictive 64K byte limits on the iAPX 286, 
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and with several times more levels than just 
the four allowed by the Intel processor. On the 
other hand, MC68020 hierarchical levels are 
totally optional and do not extract any penal- 
ties for those interested in implementing, say, 
a classical virtual demand paging mechanism. 


One could even combine the two and imple- 
ment a demand paging ring structure! 


The bottom line here is M68000 Family power 
and flexibility versus the iAPX 286 philosophy 
of rigidity and limitation. 


MEMORY MANAGEMENT 


There are many aspects of memory manage- 
ment. There are many reasons for a system to 
require its memory to be managed. The exact 
concerns of the designer must be examined 
before the technique of memory management 
can be decided. Fixed schemes of memory 
management which only fit a particular set of 
criteria suffer the same fate as processors 
which force the programmer into certain re- 
strictions and practices — they are undesira- 
ble, unpopular and fail. 


Memory management can be required in a sys- 
tem to control a number of things. Ideally, the 
more the isolation between the memory man- 
agement scheme and the programs and data 
which the processor will operate on, the better. 
The higher the level of program which must 
have knowledge of the memory management 
technique, the better. Ideally, only the highest 
level of the operating system kernel — or even 
a completely separate, intelligent memory 
manager — even knows that there is some 
form of memory management in use. That ker- 
nel manages the memory according to the cho- 
sen scheme. 


Some computer systems, however, require 
every program — whether operating system, 
utility, library or application —.to have knowl- 
edge of the memory management scheme. 
These programs have to obey certain rules of 
the scheme, and have to provide certain infor- 
mation to the manager based on each routine 
to be run, resulting in excessive memory man- 
agement overhead. This is undesirable and 
unnecessary. 


It is more typical in advanced computers for 
the application-level programs to be written as 
though they had free access to any resource 
located anywhere within the address space of 
the processor. Should the operating system 
decide that it is dangerous for the lower level 
application program to have access to a set of 
resources, the operating system will make cer- 
tain that all attempts to access those resources 
will be blocked and only the operating system 
may make them. 


This is one of the typical duties of the memory 
manager: to protect various memory spaces 
from unauthorized users. Another purpose of 
the memory manager is to translate addresses. 


A microprocessor generates logical addresses, 
based on internal address calculations asso- 
ciated with instruction processing. These log- 
ical addresses might not correspond to phys- 
ical memory or I/O locations, due to hardware 
constraints. The memory manager needs to 
control which logical memory or I/O locations 
correspond to actual physical locations, and 
properly translate the logical addresses to 
physical addresses. 


The use of a smaller (or even larger) physical 
memory space than the logical address space 
is called “virtual memory.” The exact parti- 
tioning of physical memory, and the algo- 
rithms used, comprise the virtual memory 
scheme. A variety of virtual memory tech- 
niques exist and are popular. Each has positive 
and negative aspects, and the correct virtual 
memory technique for each system must be 
selected. 


A third form of memory repositioning, banking 
or segmentation, is not so much a technique 
of managing memory as it is a technique of 
expanding memory. Banking and segmenta- 
tion were initially introduced in computer de- 
signs as a means of working around an other- 
wise small address space. They allow a smaller 
size address space to be duplicated a number 
of times by categorizing each duplicate ad- 
dress space by its purpose. This purpose may 
be as broad as classification of program versus 
data space, or as specific as data space no. 2 
for user no. 3. 
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The advantage of bank or segment memory 
schemes is that they allow more memory to 
be accessed than the naked architecture will 
allow. This is done by appending the bank or 
segment address to the beginning of the ad- 
dress. This requires no real change in the ex- 
isting processor architecture — only additions 
to the hardware and bank/segment control 
routines. 


While banking and segmenting expand the ad- 
dressing range of a processor, and implemen- 
tation is easy in the architecture, actual use of 
a banked or segmented address space is quite 
involved. The problem with banking and seg- 
mentation has always been that of keeping 
track of which bank or segment the program 
or data needed is in. Not only is the program- 
mer saddled with MMU loading instructions, 
but the overhead for loading segment registers 
(two to four microseconds for the iAPX 286) is 
always present every time the program 
executes. 


As reasonable execution time is possible only 
by keeping a small number of bank or segment 
registers active, keeping those registers point- 
ing at the most frequently used information is 
quite a chore. Then, every time the information 
needed by the processor cannot be found in 
a current bank or segment register, the appro- 
priate bank or segment must be swapped with 
an existing register. 


It doesn’t take too many of these register 
swaps to turn into quite a lot of overhead. And, 
as we have seen before, the iAPX 286 has only 
two segment registers for data. 


iAPX 286 Segments Limit Compatibility 
with Today’s Systems. Just now being in- 
troduced are single-user computer sys- 
tems which routinely handle data struc- 
tures of several megabytes in size. New 
innovations such as the Smalltalk lan- 
guage require the manipulation of huge 
linear memory elements to offer the pow- 
erful concepts they provide. 


The iAPX 286, with its 64K segment limit 
and lack of true virtual memory capability, 
is entirely unfit to be used as a host mi- 
croprocessor for such systems. 

















For example, with such advanced systems 
a single item symbolized by an icon may 
represent a complete collection of dispar- 
ate entities such as text files, spreadsheet 
data, graphic drawings, code package ele- 
ments, and, most importantly, other icons 
which themselves may contain such items. 
Such a system treats that single icon as 
a fully addressable block which may be 
many megabytes in size. If an item is se- 
lected (activated) from that icon, then it is 
also addressed and accessed in like 
manner. 


This is why a huge linear address range, 
as on M68000 processors, is so critical for 
efficient execution of such objects. Break- 
ing such items down into artificial seg- 
ments of 64K on the iAPX 286 is just not 
practical. The many items which, either as 
single entities or as groups are larger than 
64K, would create havoc with segment 
loading and testing requirements, as the 
iAPX 286 at every access into such an item 
would be required to generate a complete 
subroutine call to guarantee that the proper 
segment is based in a segment register. 
The iAPX 286 program cannot simply ac- 


MC68000/MC68010 
MOVE.L Index,Dn 
ASL.L #2,Dn 
opcode offset(Dn,Base) 


TIME (12.5 MHz) = 2.72 us 


MC68020 
MOVE.L Index,Dn 
opcode offset(Dn,Base,Dn:2) 


TIME (16 MHz) = 0.625 us 


iAPX286 
MOV BX,Descriptor 
MOV AX,Index +2 
MOV CX,|Index 
CALL RESOLVE 
LDS SI,X 
opcode [Si] 


TIME (8 MHz) = 20.37 us 





Large Array Access (iAPX 286, MC68000, MC68020) 


Bytes 


co Immo 


Bytes 
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cess any address it wants, as can those on 
an M68000 processor, but instead must 
pass such an address to a subroutine to 
determine which segment is the proper 
one to base. 


The Intel iAPX 286 Preliminary User's 
Guide gives an illustration of what must 
be done to access large data structures on 
the iAPX 286. The code is so lengthy (58 
bytes) that it must be incorporated as a 
subroutine and usually will be passed a 
descriptor since that results in shorter 
code and due to the fact that there are not 
enough registers on the iAPX 286 to pass 
all the parameters required. The following 
sample code shows the access required 
to address a large array of four byte values 
with a 32-bit index on the iAPX 286, the 
MC68000 and the preliminary figures for 
the MC68020. The iAPX 286 routine is out 
of the Intel publication. Note that for the 
Intel code to work, the operating system 
must support the incrementing on seg- 
ment identifications to address continu- 
ous segments (something not offered by 
Intel’s own operating system). 


Cycles 
16 
12 
a 
34 
Cycles 
6 
oe. 
10 
Cycles 
2 Descriptor DW Structsize 
5 DW Offset 
5 DW SegAsize 
10 DW SegA 
22 Xx DD *-* 
0 
119 (RESOLVE) | 











* RESOLVE IS ADAPTED FROM INTEL iAPX286 PRELIMINARY USER’S 


* MANUAL (FIGURE 8-10) 


* INPUT: DS:BX — DESCRIPTOR FOR ARRAY WHICH 


CONTAINS 


* *£ ee eK K OK 


RESOLVE MUL 
MOV 
MOV 
MUL 
ADD 
ADC 
JNZ 

CMP 
JAE 

MOV 
MOV 
MOV 
RET 


DIV 
ADD 
MOV 
MOV 
RET 


DI,AX 
AX,CX : 


DXx,DI 
NEW_SEG 
AX, [BX +4] 
NEW_SEG 
CX,{BX + 6] 
X+2,CX 
X,AX 


NEW_SEG [BX+4] 


AX,[BX + 6] 
X+2,AX 
X,DX 


As can be seen, the inordinate amount of 
segment handling adds an order of mag- 
nitude overhead for accessing large data 
structures such as the array. 


in fact, the iAPX 286 is over 7 times slower 
‘than the MC68000 or MC68010, and a 


Incrementing a Smalltalk or Graphics String 
Pointer. To consider just a simple thing as 
scanning a string in a Smalltalk or large graph- 
ics environment requires unbelievable gym- 
nastics on the iAPX 286, while the overhead of 
the autoincrement addressing mode on the 
M68000 processors is zero. In other words, any 
M68000 processor is so powerful that it incre- 
ments address registers by the respective data 
type size in parallel with the instruction 
execution. 


Contrast this with what is required on the iAPX 
286. First, we will assume that the operating 
system is smart enough that it can assign con- 
secutive segment identifications for contig- 


WORD SIZE OF STRUCTURE 
WORD 1ST SEGMENT OFFSET 
WORD SIZE OF SEGMENT 
WORD SEGMENT BASE ID 
AX = HIGH WORD OF 32-BIT INDEX 
CX = LOW WORD OF 32-BIT INDEX 
OUTPUT: X + SEGMENT AND OFFSET POINTER TO ARRAY ELEMENT 


AX,[BX] HIGH X SIZE 


AX,[BX] LOW X SIZE 
AX,[BX + 2] + OFFSET 
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+0 
+2 
+4 
+6 


Bytes Cycles 


24 

2 
PATH1 
PATH2 
PATH3 


125 CYCLES 
135 CYCLES 
99 CYCLES 


24 


AVG 119 CYCLES 


49 BYTES 


"A RWNHWNHNMWWNHDM W 


-hAWW 
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huge 32 times slower than the MC68020. 
Even worse for the iAPX 286 is the fact 
that only two data segments can be based 
at any one time (and even these are re- 
quired for other dedicated operations), 
further aggravating the code and time 
overhead. 


uous large data structures. (This in itself re- 
quires that massive extensions be added to 
such things as language compilers, assem- 
blers, linkage editors and dynamic memory 
allocation within the operating system to sup- 
port such a capability.) 


iAPX 286 M68000 Processors 
INC BX 2 Cycles (An) + 0 Cycles 
JNE LBL 16/4 Cycles Autoincrement 
addressing mode 
MOV DS,AX 2 Cycles 
INC AX 2 Cycles 
MOV DS,AX 20 Cycles 
LBL 
Result: 10 Bytes 18 or 30 Cycles 0 Bytes 0 Cycles 


1 Extra Register No Extra Registers 














The difficulty in implementing such a trivial 
thing on the iAPX 286 doesn’t even begin to 
give an indication of the more complex ma- 
nipulations required when a complete scalar 
item straddles a 64K boundary and must be 
accessed by a high-level language. Several 
pages of code are required to accomplish that 
feat on the iAPX 286, and they are omitted 
here. 


Artificial Intelligence Research Cannot Use the 
iAPX 286. As reported in the Wall Street Jour- 
nal on August 19, 1982, page 19, researchers 
say that the iAPX 286 cannot be used for ar- 
tificial intelligence applications: 


“ .. The 68010 is an improved version of 
Motorola’s 68000 microprocessor, which is 
forming the basis of dozens of new desktop 
computers. 


“, . International Business Machines Corp. 
and Hewlett-Packard Co. recently began sell- 
ing computers based on the 68000, too. At 
least four groups of scientists — at Yale, 
Massachusetts Institute of Technology, the 
University of Utah and the Rand Corp. — are 
at work on or say they have completed Lisp 
dialects for the 68000. 


“.,. An informal survey of the major centers 
of artificial intelligence research found no 
one trying to develop a Lisp dialect for the 
microprocessors with which the Intel Corp. 
competes against Motorola. Scientists sur- 
veyed say Intel’s present circuit, the 8086, 
can't deal with enough information at one 
time to be useful in major artificial intelli- 
gence programs and they dislike the design 
of the improved version [iAPX 286] due from 
Intel soon.” 


Large data structures and efficient use of point- 
ers are absolutely critical for proper operations 
in such environments. The fact that the iAPX 
286 cannot handle virtual memory access 
faults, but forces segment loading checks and 
their associated overhead (shown earlier), re- 
stricts its use to the 8-bit world of 64K address- 
ing. Each segment register load on the iAPX 
286 requires 20 clock cycles. And the iAPX 286, 
with its small and special purpose register set, 
requires a massive amount of segment register 
manipulation as shown in the EDN Quicksort 
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benchmark — where the entire MC68000 ex- 
ecution time is faster than just two of the seg- 
ment loading instructions for the iAPX 286 na- 
tive mode version. 


Dynamic Storage Areas and Sophisticated 
Software Systems. Many benchmarks around 
are extremely simple and do not really tax 
the architecture of even the simplest 8-bit 
microprocessor. However, real world com- 
puter systems require the successful exe- 
cution of large and sophisticated program 
modules with their associated linkage. As a 
result, many weaknesses are hidden and 
only found after a system is fully 
implemented. 


Intel’s limited segment sizes have several 
such side effects which need to be brought 
to light. By exposing just a single example 
here, it will be seen that the problems caused 
are far from trivial, and it behooves anyone 
investigating the use of various micropro- 
cessors to ferret out just such anomalies 
prior to selection. 


A sophisticated system requires the inter- 
action of tens or maybe even hundreds of 
modules. Each module, when called, de- 
mands access to new and unique dynamic 
storage areas for such things as large local 
variable structures and stacks for temporary 
work areas, dynamic data allocation and 
subroutine return linkage. Such dynamic 
areas cannot be static (that is, allocated at 
linkedit or module load time) as the module 
may be called directly by itself, indirectly by 
routines called by itself, or by a completely 
different task. Dynamic areas are also re- 
quired for recursive programmimg tech- 
niques. In fact, most modern programming 
languages—such as Ada, Pascal, and Lisp 
— have all modules recursive as a matter of 
language definition. 


On any M68000 microprocessor, the matter 
is simply and automatically handled via its 
large linear address space. 


As a routine is called, it merely allocates the 
dynamic memory it requires on the current 
stack and continues on its way. The powerful 
LINK instruction allocates the fixed stack re- 


quirements for local dynamic data items and 
sets up any one of the address registers as a 
frame pointer. Since each and every executing 
module uses the stack dynamically, there is 
never any wasted space or management over- 
head (see Figure 13). The operating system can 
easily assign an initial stack and then increase 
it by a set amount whenever required as de- 
tected by virtual memory faults. Motorola Pas- 
cal, for example, has the main program allo- 
cate all global data initially on the stack. Then, 
as each function or subroutine gains control, 
it simply uses the LINK instruction to allocate 
its total requirements directly on the same 
stack. At termination, the UNLK instruction 
does the simple work of freeing the data. 


Start of Stack 


A’ Local/Dynamic 
Top of Stack 


NOTE: All areas accessible with a single addressing mode (4 
cycles.) 


Figure 13. Dynamic Storage Allocation on M68000 Processors 


The iAPX 286 has no obvious way of handling 
dynamic areas, a problem to contend with in 
the iAPX 286 runtime enviroment. 


When the iAPX 286 ENTER instruction at- 
tempts to extend the stack, it fails whenever 
the total dynamic area in use by all modules 
becomes greater than 64K. Thus, Intel’s at- 
tempt to include a few M68000-like instructions 
in the iAPX 286 instruction set does nothing 
but point up the inadequacy of the iAPX 286 
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architecture to support today’s sophisticated 
requirements. Even worse is the fact that the 
stack size limitation means that the local dy- 
namic variables often will not fit into a single 
64K segment, and thus some artificial means 
must be developed for allocating and freeing 
such storage. Complicating the problem for the 
iAPX 286 is the fact that segment values cannot 
be “played around with” as on the older 8086. 


The end result of all this is that very cumber- 
some methods must be employed to support 
dynamic variables and stacks on Intel archi- 
tectures. What takes a single instruction in a 
module to allocate or free the stack and vari- 
able space on any M68000 microprocessor, 
takes entire subroutines on the iAPX 286. And 
for dynamic memory segments to be effi- 
ciently reused, these subroutines must be 
called both before and after each module ex- 
ecution, since the dynamic order of module 
invocation cannot be predicted. Figure 14 gives 
an indication of the extra descriptors and over- 
head required for dynamic storage manage- 
ment with the iAPX 286. And remember: each 
descriptor load to reference any of these areas 
is over two microseconds (assuming 80 nano- 
second memories). 


As if this were not enough, the iAPX 286 high- 
level language runtime environment must often 
interface with the iAPX 286 operating system 
via call gates, since the descriptors pointing to 
blocks of memory segments can only be as- 
signed and manipulated by higher priority pro- 
tected routines. The total price exacted for such 
heavy encumbrances represents at least sev- 
eral orders of magnitude increase in processor 
time, just to manage the simple task of dy- 
namic stack/variable allocation. 


This is the very same problem which caused 
the Intel iAPX 432 to execute a recent set of 
benchmarks more than ten times slower than 
the MC68000. 








The following examples illustrate the code required for all dynamic memory management. 


MC68000 Method 


* ALLOCATE DYNAMIC AND LOCAL MEMORY 
LINK #SIZE,An 16 Cycles 


PROGRAM BODY 


* FREE DYNAMIC AND LOCAL MEMORY 
UNLNK An 12 Cycles 





iAPX 286 Method 


; ALLOCATE OUR OWN STACK FOR TEMPORARIES AND SUBROUTINE CALLS 





CALL NEWSTACK Hundreds to Thousands of Cycles 
; ALLOCATE LOCAL DATA STRUCTURE SEGMENT 

MOV AX,SIZE 3 Cycles 

CALL ALLOCSEG Hundreds to Thousands of Cycles 


; REPEAT ABOVE FOR EACH LARGE STRUCTURE REQUIRED 
| PROGRAM BODY 
: FREE LARGE STRUCTURES 
MOV BxX,DESCRIPTORADDRESS 7 Cycles 
CALL FREESEG Hundreds to Thousands of Cycles 
; REPEAT ABOVE FOR EACH STRUCTURE OBTAINED 


: FREE DYNAMIC STACK AND RETURN TO CALLER 


JMP FREESTACK Hundreds to Thousands of Cycles 
\ Segment 
Global 
I Variables 
' Segment 
Segments 


Descriptors Main Local 
a i 
a Data Structures l 


Descriptors ! A Local Data 
SY ‘ 
| Structures | 


| Segment 
Subroutine B 
\ Stack/Temps 


Segments 


Descriptors 5 B Local Data 
| i 
I Structures | 





Segment 
Subroutine A” 
| Stack/Temps 
i 


Segments 
Descriptors A A’ Local Data 
ae | Structures T 
NOTE: Several instructions require over 2 microseconds to address a different 


segment. 


Figure 14,.. Dynamic Storage on the iAPX286 
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Massive Descriptor Overhead for All iAPX 286 
Native Mode Operating Systems. There are 
many hidden pitfalls awaiting the operating 
system programmer who is forced to use the 
iAPX 286 method of MMU descriptor control, 
besides the fact that most of his current op- 
erating system will need substantial rewriting. 
Problems abound, as shown in Intel’s own 
iIAPX 286 Preliminary User’s Manual. 


One such example is that even before you build 
a descriptor you must first address it to build 
it. This entails the creation of yet another tem- 
porary descriptor reserved for just such activ- 
ities to allow access to the new one to be built. 
Temporary descriptors are required even to 
just examine another descriptor. The added 
execution time overhead of such little nuances, 
and there are many, comes as a grim discovery 
for those who examine the iAPX 286 for their 
operating system base. 


VO INTERRUPTS ON THE MC68000 
AND THE iAPX 286 


The following code shows the EDN benchmark 
requirements for the iAPX 286 benchmark A. 
The original code “as published” will not work 
on the iAPX 286 because the protected mode 
will not allow code space to be written to as 
was done on the 8086 (a decidedly uncom- 
fortable incompatibility for Intel to acknowl- 
edge). The earlier EDN code would receive a 
protection exception 13 due to an access rights 
violation. 


The protected iAPX 286 environment allows 
three ways to handle an interrupt. The first and 
“fastest’’ method is to have a single task sys- 
tem which runs all program segments at the 
same priority and allows the interrupt to be 
taken also at the same priority. The second 
method processes the interrupt at a higher 
priority level (which would ordinarily be the 
case) and also allows multiple tasks to be used. 
For small, single-purpose multitasking sys- 
tems, this would be the norm. The third method 
is via a task switch. Since this third method is 
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quite inefficient, it would only be used for very 
unique conditions where a complete high 
priority task is required to process a special 
case of infrequent interrupts. 


M68000 Version. M68000 Family interrupt code 
is simple and fast. Intel presents the same 
benchmark in their “iAPX 186,286 BENCHMARK 
REPORT” of October 1982. In order to make it 
appear that the iAPX 286 is faster, Intel incor- 
rectly claims that an interrupt handler on the 
MC68000 must change MMU segment regis- 
ters during interrupt processing. 


The truth is that the Motorola MC68451 MMU 
itself detects a change from user to supervisor 
state and uses the supervisor descriptors au- 
tomatically. Since the MC68451 does not have 
64K limits on its descriptors, as does the iAPX 
286, operating systems using the MC68000 
typically permanently map their entire resident 
operating system memory requirements with 
just a few permanent descriptors. Thus, the 
entire operating system runs with never once 
causing a descriptor fault and incurring the 
associated overhead. Contrast this with the 
constant descriptor loading required of an 
iAPX 286 operating system. 


Another reason for simplicity of the MC68000 
interrupt routine is its absolute address capa- 
bility. Notice that the iAPX 286 must labori- 
ously save registers and rebank its data seg- 
ment to achieve pointer capability, something 
freely available with a simple addressing mode 
on the MC68000: 


Cycles 
*ENTRY 44 
16 ADD #1,COUNTER INCREMENT COUNTER 
20 RTE RETURN FROM 
80 EXCEPTION 


Fastest iAPX 286 Version. The fastest handler 
is the same priority handler, and can only be 
used in very primitive, single-task iAPX 286 
systems. The handler must save at least one 
of the interrupt routine’s segment and base 


registers so that the interrupt counters can be properly based: 


Cycles 
* ENTRY 41 
3 PUSH 
3 PUSH 
21 LDS 
7 INC 
20 POP 
5 POP 
32 IRET 
132 


Most Common iAPX 286 Version. Normally, 
interrupts must be handled at a higher priority 
than problem program code, and thus different 
interrupt and return times come into play since 
a different stack is now forced to be based by 


Cycles 
* ENTRY 79 
3 PUSH 
3 PUSH 
21 LDS 
7 INC 
20 PoP 
5 POP 
56 IRET 
194 


Task Switch iAPX 286 Version. The task chang- 
ing would be rarely used. Only when a very 
special and infrequent exception needs to trig- 
ger a complete high priority task switch would 


Cycles 
* ENTRY 167 
3 PUSH 
3 PUSH 
21 LDS 
7 INC 
20 POP 
5 POP 
170 IRET 
397 


S| ;SAVE INDEX REGISTER 
DS ; AND SEGMENT REGISTER 
SI,CNTPTR ;BASE COUNTER 
[St] sINCREMENT IT 
DS ;RESTORE SEGMENT 
S| ; AND INDEX REGISTER 
the protection scheme. The code itself remains 
the same. However, the interrupt routine must 
only reference the global descriptor table (GDT), 
since any task may have been interrupted. 
sl ;SAVE INDEX REGISTER 
DS ; AND SEGMENT REGISTER 
SI,CNTPTR ;BASE COUNTER 
[St] sINCREMENT IT 
DS ;RESTORE SEGMENT 
S| ; AND INDEX REGISTER 


this come into play. However, any iAPX 286 
operating system allowing programs to supply 
direct interrupt handlers must use this method 
to guarantee system integrity. 


Sl ;SAVE INDEX REGISTER 

DS ; AND SEGMENT REGISTER 
SILCNTPTR ;BASE COUNTER 

(Sl ;INCREMENT IT 

DS ;RESTORE SEGMENT 

Sl ; AND INDEX REGISTER 
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Summary. Intel claims (in Advanced Informa- 
tion Book AFN-02060A) that cycle times will 
average 5% more due to instruction fetch wait 
from memory. Also, these times assume zero 


wait states, which require at least 80-nanose- 
cond memory. The following chart shows the 
comparison of the two systems under a wide 
variety of conditions: 


Interrupt Increment and Return 


MC68000 without MMU 12.5 MHz 6.4 microseconds 
MC68000 with MMU 10.0 MHz 9.3 microseconds 
8086 10.0 MHz 11.6 microseconds 
iAPX 286 80 ns memory (same priority) 8.0 MHz 16.5 microseconds 
iAPX 286 same memory speed (same priority) 8.0 MHz 24.7 microseconds 
iAPX 286 80 ns memory (to other priority) 8.0 MHz 24.2 microseconds 
iAPX 286 same memory speed (to other priority) 8.0 MHz 36.4 microseconds 
iAPX 286 80 ns memory (task switch) 8.0 MHz 43.1 microseconds 
iAPX 286 same memory speed (task switch) 8.0 MHz 64.6 microseconds 


Notice that the 8086 beats the iAPX286. 


Another important statistic is the longest in- 
terrupt latency possible, from the generation 
of an interrupt to the first instruction of the 


MC68010 Cycles 
DIVS.W d(An,m) 136 
VO INTERRUPT 46 

182 


Finally, assuming that the iAPX286 does not 
allow the use of task gate interrupts, worst case 
timing is: 


Cycles 
Call task __ gate 188 
1/O interrupt _81 
269 


Intel Architecture Foils Intel’s Own Program- 
mers. A prime example of the problems caused 
by the 8086/iAPX 286 architectural weaknesses 
is an examination of the code produced by 
Intel’s top programmers for the EDN bench- 
mark competition. The last benchmark of that 
series (benchmark K) inverts a square bit ma- 
trix of size seven by seven. That competition 
was originally published in the April 1981 edi- 
tion of EDN. 


Intel's time for that benchmark was 820 micro- 
seconds for the 8086 versus 368 microseconds 
for the MC68000. The Motorola version was a 


interrupt handler. The worst case for both sys- 
tems is: 


iAPX 286 Cycles 
CALL task — gate 188 
I/O INTERRUPT (TASK GATE) 170 
358 
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very simple one, where a virtual bit address 
was created by shifting the byte address over 
by three and appending the bit number thereto. 


A second edition of the benchmarks was run 
in EDN’s September 16th issue of the same 
year, and Intel submitted a new version for 
benchmark K. In it, they attempted to create a 
virtual bit address just as Motorola had done. 
However, they ran into one major problem: 
their new benchmark would not work with the 
vast majority of possible parameters since, 
with only 16-bit registers, when they shifted 
left by three they were throwing away the top 
three bits of the bit array address. The MC68000, 
with 32-bit registers, has no such loss of pre- 
cision. For the Intel architecture, this meant 
that parameters located within 7/8ths of the 
address space would cause the routine to com- 
pletely fail. 


When Motorola contacted Intel about the flawed 
benchmark, Intel responded that bit matrixes 
located at such addresses were invalid to pass 








to the subroutine. In other words, parameters 
which fail are simply not valid parameters. 
Such tunnel vision is a neat way to cover up 
the problem, but the simple fact still remains 
that the benchmark does not work. 


Unfortunately, for users of the 8086/iAPX 286, 
in the real world we cannot build a software 
system and then loftily claim that anything 
which makes it fail is invalid. 


And, by the way, you can guess which version 
Intel is now using to claim that the iAPX 286 
speed compares with the MC68000. One won- 
ders about benchmarks which don’t work. 


PACKAGING 


Since not all applications are able to take ad- 
vantage of a single package type, it is impor- 
tant that components be available in packages 
that fit a wide range of enviromental con- 
straints. The MC68000 is currently available in 
the following packages: 


Dual-in-line ceramic 3.9 square inches — 
standard package ("L” Suffix) 

Dual-in-line plastic 3.9 square inches — 
internal heat spreader (’G” Suffix) 
Dual-in-line plastic 3.9 square inches — 
lower cost version (’P’’ Suffix) 


JEDEC type B — LCC 1.0 inch square — 
socketable (“ZB” Suffix) 


JEDEC type C — LCC 1.0 inch square — 
solderable (“ZC’’ Suffix) 


Pin Grid Array Package — 1.0 inch square 
— both socketable and solderable (”R” Suffix) 


Power Considerations. System designers, when 
choosing microprocessors, should include worst 
case power dissipation as an integral part of 
their performance rating procedure. High power 
dissipation requires effective and often costly 
thermal management to achieve system per- 
formance goals. 


“Worst Case” Calculations. The first step in 
any determination of the impact of device 
power is a “worst case” calculation of the de- 
vice juction temperature (Tj) using data sheet 
specifications. The specification for maximum 
power dissipation, along with maximum am- 


bient temperature, and worst case thermal re- 
sistance (theta.ja), can be combined to derive 
the worst case junction temperature. The equa- 
tion below can be used to calculate this 
temperature: 


Tj = Ta + Pd * theta.ja 
Additionally, some equation for derating power 


dissipated as a function of temperature such 
as: 


Pd = K/(Tj + 273 ), where Tj is the temper- 
ature in degrees centigrade. 


A “worst case” power dissipation analysis will 
be presented for the following devices: 


MC68000ZB — Type B socketed chip carrier 
MC68000G — 64 lead Plastic DIP 
iAPX 286 — Type A socketed chip carrier 


MC68000ZB Calculation: 


max power = 1.5 Wat Ta = 0°C 
max temp = 70°C 
theta.ja = 50°C/W 
Pd = 1.28 W at Ta = 70°C 
Tj = 134°C 
MC68000G Calculation: 
max power = 1.5 Wat Ta = 0°C 
max temp = 70°C 
theta.ja = 30°C/(W 
Pd = 1.25 W at Ta = 70°C 
Tj = 108°C 
iAPX 286 Calculation: 
max current = 600 ma at 25°C 
max voltage = 5.5v 
max power = 3.3 Wat Ta = 25°C 
max temp = 70°C 
theta.ja = 50°C/W 


Pd = 3.1 W at Ta = 70°C 
Tj = 224°C 


Note the junction temperature for the iAPX 
286. 


Conclusions. Now that the “worst case” ther- 
mal analysis has been performed, how would 
a system designer use the results to determine 
the amount and cost of thermal management 
(if required to achieve a safe upper limit for 
Tj)? Traditionally, a safe upper limit for Tj has 
been subjective, and related heavily to relia- 
bility. A general guideline is that the junction 
temperature should be 125°C for the “worst 
case” thermal analysis. When the junction 
temperature is higher, the reliability of the de- 
vice decreases correspondingly. 


All devices discussed here, except the 
MC68000G,require some amount of thermal 
management, ranging from very little for the 
MC68000ZB to a great deal for the iAPX 286. 
The type of thermal management usually em- 
ployed is the addition of heat sinks to the pack- 
ages, and the assurance that there is a source 
of high-velocity air flow available to the heat 
sinks. 


The junction-to-case thermal resistance char- 
acteristic (theta.jc) is useful in calculating the 
junction temperature, assuming that thermal 
management has effectively reduced the 
theta.ca to zero, and has made theta.ja equal 
to theta.jc. The JEDEC Type A socketed chip 
carrier used for the iAPX 286 has a theta.jc of 
13°C/W. This results in a junction temperature 
of 108°C for the iAPX 286, which is the same 
as for the MC68000G with no thermal man- 
agement. The same amount of thermal man- 
agement for the MC68000ZB would achieve a 
theta.jc 17°C/W and a resulting junction tem- 
perature of 91°C. 


SUMMARY 


The definition of a microprocessor’s architec- 
ture involves many tradeoff decisions and im- 
pacts in very important ways the speed, effi- 
ciency and reliability of any computer system 
based on that architecture. 


The Motorola M68000 Family of microproces- 
sors implements a clean and powerful 32-bit 
architecture with general purpose registers 
and orthogonal addressing modes. A break 
with full compatibility to older 8-bit architec- 
tures was necessary so that advanced con- 
cepts could be introduced by the all-new 8/16/ 
32-bit M68000 Family. The result was a new 
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architecture which encompasses features re- 
quired of today’s system solutions and those 
for the rest of this decade and beyond, with 
complete user object-code compatibility. 


In contrast to M68000 architecture, the iAPX 
286 is weighted down with the instruction set 
of the much older 8086, with all of the cum- 
bersome attributes associated with such an- 
cient chip designs. 


As a result, such crippling concepts as seg- 
mented addressing and special purpose reg- 
isters rule the inflexible philosophy of iAPX 
architecture. These exact their harsh penalties 
in a multitude of ways, including excessive 
object code generation — which causes painful 
complexities in the integration of large, intri- 
cate software systems — and forcing at least 
seven times slower-than-M68000 execution in 
the accessing and addressing of large array 
and data structures. 


The decision to implement direct 16-megabyte 
linear addressing was one of the greatest fac- 
tors in the industry-wide acceptance of the 
M68000 Family. Contrast this to the mere 64K- 
byte segmented accesses of the iAPX 286. This 
forces extra manipulations on programmers, 
who must constantly attempt to contort their 
way around the severe limitations of restrictive 
registers and addressing modes. 


The iAPX 286 does not even support virtual 
memory, but only a virtual segment restart ca- 
pability. Contrast this with the virtual I/O, vir- 
tual machine and virtual window concepts 
available with Motorola’s M68000 architecture. 


The 32-bit architecture of M68000 Family mi- 
croprocessors stands in stark contrast to the 
16-bit segmented 8086/iAPX 286. Remarkable 
differences appear in performance, implemen- 
tations, ease-of-use, code and execution effi- 
ciency between the two architectures when 
they are applied to actual programming 
environments. 


In all important respects, the M68000 Family 
is seen to be far superior to the antiquated 
8086/iAPX 286 architecture and fulfilis the 
more sophisticated needs and requirements of 
today’s demanding software systems and 
methodologies. 











APPENDIX A 
MC68000 Pascal is 45% Faster than 
iAPX 286 Pascal 


Intel has recently claimed better performance 
for the iAPX 286 over the MC68000 in bench- 
mark publications. 


However, what they fail to tell customers is that 
the iAPX 286/8086 architecture is so inefficient 
that the Pascal benchmarks show a whopping 
45% more bytes of code must be fetched to 
perform the exact same function. 


The implications are obvious. Since the ma- 
jority of bus cycles are fetching instructions 
(about 80% on the average), the iAPX 286/8086 
must fetch 45% more program code to com- 
plete an equivalent function on the MC68000. 
Thus, for a given memory speed, the MC68000 
executes these benchmarks significantly faster 
than the iAPX 286 possibly can because the 
iAPX 286 must fetch SIGNIFICANTLY MORE 
DATA (i.e., instructions.) 


This analysis does not even begin to get into 
the overhead which will be required for the 
iAPX 286 native mode execution. The Pascal 
library code size was not included in the sta- 
tistics gathered and therefore there is no such 
bias involved. 


The much larger code size required is man- 
dated by the inefficiencies of the Intel archi- 
tecture, such as segment overhead, limited 
number of registers and forced dedicated reg- 
ister usage. These benchmarks will soon be 
rerun on the even faster MC68000 Pascal com- 
piler and the results will be even more 
spectacular! 
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Berkeley Benchmark Series Size in one 


Mc6s000 _| iAPX 286/8086 


Search 31% 
290% 
32% 
250% 
151% 

Average 


Sieve 


Puzzle 
Acker 





The results are quite clear. The MC68000’s sig- 
nificantly reduced instruction needs allow it to 
spend more time completing a customer's pro- 
gram requests instead of wasting time decod- 
ing what to do. 


APPENDIX B 
Independent Benchmarks Show 
MC68000 Faster than iAPX 286 


The following times for a wide variety of 
Motorola and Intel microprocessors are for an 
EDN benchmark study published in EDN mag- 
azine April 1, 1981, and September 16, 1981. 
The results show that the Motorola MC68000 
without MMU beats the iAPX 286 in all cases 
and, with the MC68451 MMU, betters the iAPX 
286 in the majority of cases. Note that Intel’s 
new iAPX 186 turns out to be slower overall 
than the much older 8086 it is meant to replace, 
and that the new iAPX 286 is only 38% faster 
than the original 8086, even with significantly 
faster memories. 


Also of interest is the fact that the MMU on 
board the iAPX 286 causes so much interrupt 
overhead that not only the old 8086 but the 8- 
bit MC68008 outperform it on the first 
benchmark. 


The following code shows that there are not 
enough registers on board the iAPX 286 mi- 
croprocessor to accomplish even a simple sub- 


0022 
0023 
0024 
oo25 
0026 
0028 
002A 


oo2n 
0028 
oo2c 
o02D 
Oo2F 
0032 





E81790 


EDN BENCHMARKS 


(1) (2) (3) 
MC68000L12 | MC68000+MMU MC68008 


(1) MC68000 at 12.5 megahertz, no wait states. 
(2) MC68000 with MC68451 MMU at 10 megahertz, one wait state. 
(3) MC68008 8-bit microprocessor at 10 megahertz, no wait states. 
(4) 8086-10 at 10 megahertz, no wait states. 
(5) iAPX 186 at 8 megahertz, no wait states. 
(6) iAPX 286 protected mode (MMU turned on) at 8 megahertz, no wait states. 


Quick sort 


zA-IMmMg> 


I/O Interrupt: four interrupts, increment and return 
/O Interrupt; queue interrupts 

String search 
Bit test/set/reset 
Linked list benchmark 


Bit matrix inversion 


(4) (5) (6) 
8086-10 iAPX 186 iAPX 286 


NOTE 1 All Motorola speeds available now as regular production. Intel 80186 (iAPX 186) 
and 80286 (iAPX 286) 8 megahertz parts will be available when regular production 
commences, according to the manufacturer. 

NOTE 2 All MC68000 code the same. Some 8086 and 80186 code changed by Intel to allow 
iAPX 286 protected mode execution. 


APPENDIX C 


iAPX 286 Substring Benchmark 


+} THE BENCHMARK PRCICEDURE 


CHARACTER SEARCH 


ASSUMPTIONS: 1 VALID DAT. 
AND MINLN 


weer ew weer even 


#SAVE WORK REGISTERS 


PUSH AX 
PUSH Dx 
PUSH cx 

cLD 

mov aL, CSI) 
suB Cx. BX 
INC cx 


1FINO MATCH TO FIRST CHARACTER 


TRYNXT: 
REPNE SCASB 


vE MATCH) 
NOTFND: MOV DI.-1 
JP DONE 


+FIRST CHARACTER MATCH HAS BEEN 
1 COMPARE THE REST OF THE STRING 
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string character search. Lines 93, 95, 102, and 
103 save and restore the overworked SI and DI! 
registers. 


EDN BENCHMARK FOR IAPX 86 


A FOR SRCHLNGTH 
CTH (SRCHUNGTHMINNGTH) 


2 PARAMETERS ARE PASSED IN RECISTERS AS FOLLOWS: 


ES:DI  TABLE_PTR 
DS:SI_- STR_PTR 

cx TABLE_LNOTH 
DX STR_LNGTH 


3 THE LOCATION OF THE STRING IS RETURNED IN DY 
4 WORKING REGISTERS (AX & DX) ARE PUSHED AND POPPED 


1SAVE LENCTH 
1LOAD FIRST CHAR 


ILENGTH DIFFERENCE 
+POSSIBLE SEARCH COUNT 


1SCAN WHILE NOT EGUAL 
+ JUMP ON MATCH 

+SET NOT FOUND FLAG 
sEXIT 


FOUND 








0035 88D! 
0037 $7 
0038 SICB 
003A 56 
0038 4F 
003C F3 
003D Aé 


OO3E SE 
OOSF SF 
0040 BBCA 
0042 7404 
0044 EXE9 
0046 EBE3S 


0048 SF 
0049 2BFA 


004B SA 
oo4c 58 


004D ¢3 


ASSEMBLY COMPLETE. 


121 
122 


NO ERRORS POUND 


MATCHi: MOV OX. cx 
PUSH DI 
Mov Cx. BX 
PUSH st 
DEC D1 
REPE CMPSB 


sSAVE POSSIBLE SEARCH COUNT 
+SAVE PLACE IN TABLE 

+LOAD STR_LNGTH 

s SAVE STR_PTR 

‘RETEST FIRST (IN CASE LEN@1) 
s COMPARE STRING 


i DROP THROUGH IF THE STRING DOES NOT MATCH OR WHEN 
3 CXeO (THE ENTIRE STRING MATCHES) 


POP SI 

PoP oI 

mov cx, DX 

JE FOUND 

JCXZ NOTFND 

UMP TRYNXT 
FOUND: POP bof 

SUB DI. DX 


sRESTORE REGISTERS 


DONE: PoP DX 
POP AX 
RET 


BNCHPROG ENDP 
code ENDS 
END 
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sRESTORE STR_FPTR 

sRESTORE PLACE IN TABLE 
»RESTORE POSSIBLE SEARCH COUNT 
sSTRING MATCHES 

1END OF STRING, NO MATCH 

a TRY NEXT BYTE IN TABLE 


sCET TABLE_LENGTH 
sCOMPUTE PTR TO STR IN TABLE 


sRETURN TO CALLING ROUTINE 


SALWNOI SNOJNWTIAZOSIW » 


99% *SaLAq 
28 *SANI7T 
ANILNOW SIHL YIAO LNSYVdSNWYL JYY SYALSIOdYy TV 
G3LYOS SI AWHUW WLVG JYOS AHL *LNdLno 
AWYUW LYHOS FHL JO SSAYUddY wDdu. - BW 
LYOS NOILUASNI YOd GIOHSAYHL wWa - TO 
LNNOD GYOOSY waNwa ~ 8G ?LNdNI 


* 


ONIYVdWOD ANNILNOD A>(1)93u aI TdOO1T IH D479 BESBH08B 
WWNOD 31IHM dOO7 TdWO’ 6d anag 24448995 37609008 
(I) D3u-A auvdWoD + (pw) 4+(Swv) @°dWo TdWD ag6a V7980008 
YaLNNOD dOO1=ea 60‘ T-N3TAINE 1° GAOW 986L 87Ba99008 
I ¥Od dW3aL SV cv’7tw 1° dAOW WbVZ 92080008 
T+I -> I ZV’ (ZW) NFTAULNG va @TOBV3ISh 7Z7B99080 
GuOoaNy LNIYUND YOd A <- bw pw’ (ow) Ady wa 1Td001 €OOB8I6b ATHRBHBB 
(T+u) Ogu = (fC) ABM <- Cw EWS (CTW) ASN4+NGTAULNG vaI CTOG6AL) VIGGOGRB 
(Today = (I)AIM <- ZW cw’ (gw) AaM wal LYOS €OB989SbY 91808900 
SLNAWNDYY TIWO.aAISUNOTY - dS SGYOD3Y aWe. JO HLONST - 9V * 
SUALNIOd WHOM — SW/PW SUBLNIOd AIM - EV/7WV * 
@1IdagnsS JO aquooad LSvI - Iv 311agns dO GuODaY LsuyId - OY *4SN YALSIOIY » 
3SWHd LYOSWNOING s 
ALdW3 MWOWLS LYOS WUYW (as}- bs in: Ws fe) LVZb ¥T200008 
WOWLS NO dOL GNW ‘LNNOD “AWWNG JAWS (dS)-‘TwW/za/e@aq ‘T°WZAOW BPOVLIBY BI HBGBBO 
UGLWI YOA OW NI ANIVA dgay gv‘Taq ‘T°dAOW TpOZ 39090800 
squoogu W dO 43ZIS IWLOL ONIa Ta‘ vt 1°1S1 6869 D9688800 
Yd = GuOOTY LSVT OL USLNIOd -> TW 1V¥’(1°@0’ OW) NZTAULNG- wa BISEBACY SBBBBBBO 
QuOO3u LSVI1 OL YSLNIOd FLVINOIWO oa’ T°IS7T 8869 99800808 
YSAO SGYODSY 4O UYUSEWNN AdOD za‘’ea 7°3AOW BAZ FOBBBOBB 
SUALSIOIY T1W FAVS (dS)-’9W-9V/Ld0-8d ‘I°W3AOW wOINS a3dddL398b 80000008 
SNILNOUANS LYOSNDING * 
HLONAT AIN LYOS L nda Na1A9xN Legpeeae 
GuOO3N NIHLIM ASN OL LISAIO € nda Ag €9090080 
HLONIT GYOOdu AYLNA LYOS 9T NOS’ NaTAULNI 81808809 


SBSese QB 8&2 


39 


GNWYULNAGY » 
LNGIAGNAdGGNI NOILISOd » 
GONWY SSGUGdW SALAGVOGW 9T « “%SaILNGINLLy 
LYOSNIING 


I YUYVWHONGE NGI B8B89OW 


eeeunumeeneen nae eaeeee nae 


suq Ldo 


H40S49IND 00089DIW 21040301 
dg XIGNAddV 


aANMGFNUOEF OAS 
~ 


Squooau W IWNOS YO MO1ga SA1IGENS TIv-SV¥ LYOS NOILUSSNI OLNI T1W4a « 


ALdWa LON dI LYOS JNNILNOD 
ALdWa SI WOWLS aI LS3L 
MOWLS WOUd UY GNW 7 LX3N dod 
ON JI HONWUa 

aZISW => (C-Y) Juwdwod 

ON dI HONWua 

aZISW => (1-f) 3uYdNWOD 


1-£ -> za 
c-4 -> Ia 

cf -> Za 

u-> Id 

(cf) O34 ig 

any * 

(1) 944 : 

dv¥MS 

GuOO3Y JO ONINNIOSA OL 13D OL ARN- 
JOWLS 


LYOS JNNILNOD 
QWVS FHL SAVLS ¥ ‘THE -> 1 

MWOWLS LYOS OLNO £ 3 1 HSNd 

SLIWIT 31IdA9GNS UsoUVI 

OLY 31 «L3S ‘YaTIWWS 3aTIaGNS (1-L) 
LYOS ANNILNOD 

GWWS SHL SAWLS 1 ‘T-£ -> U 
SLIWI1 STIASGNS WIDOT 

OLY 3? 1 LaS “YSTIVWS 3TIagNs (r-H) 
cf yowLs 

Yu WOWLS 

YWATIVWS SI (1-f£) aI HONWUE 

J1IdMGNS YITIVWS JNIWUSLIG 

OS dI HONWUa 


€xaTIVWS BTIAGNS (C-u) 23ZISW => (C£-u) 


ANNILNOD 

(1) 534 if 
HLIM s 
(f)oau : 
dWMS 

fC =< I aI HONWUE 
P=<.1 

ONIYYdWOD SNNILNOD A<(C)Og3u aI 
Iwn0a 3TIHM dO0O1 

A-(f)9au a3uWdWOD 

YSLNNOD dOO7T 

Cf YOd dW3L = SV 

t-cr- ec 

GuYOOSH LNIYNND JO (A)ARM <- PY 


LuOs 
ga‘ av 
tw/ow’+(ds) 
TY IM3N 

Ta‘ 9yv 

Ou IMIN 

za‘ ow 

za’ aw 
ta‘za 

ca‘ ew 

ta‘ tw 

(aw) ‘La-va 
(ev) ‘€a-ga 
La-bd’ (€v) 
ta-#a‘ (ev) 
€w‘Agne 


3Nd 

1° 3AOW 
T°WIAOW 
IH 

T° dWO 
IH8 

T° dW 
T°ans 
1°ans 
1°SA0W 
1° 3AOW 
T°W3AON 
‘1°W3AOWN 
T°W3AOW 
T°W3A0OW 
T°ans 


LSTGNG 


JXUN SNIWUSLIG MON ‘GNNOd 3TIAGNS MUN » 


LuOS 
Ov‘ (€V) NATAULNG 
(dS) -‘€v/ow 


Luos 
Tw’ (€W) NA TAULNG- 


(dS)-‘ €w 
(dS)-‘TwW 
TIOWLS 
za‘ta 
YMGN 

Ta‘ ow 
NOILOgUIG 


Td0O0T 

(Z¥) Agu-* La-va 
(e€v) Adu-’ €a-ga 
4d-pa‘ (€v) Aay- 
€q-90' (7v) Agu- 
LSTONG 

zw‘ ew 

Z7dOO7T 

ZdwW5‘ ea 
+(Sw) ‘+ (pw) 
80’ T-Na1Ag9NF 
sv ‘ew 

ew’ (€W) NQTAULNG- 
by’ (ow) Agy 


wud 
WaT 
T°W3AON 


wud 
WIT 


1° dAOW 
1° 3A0W 
So@ 

T° dWwo 
3198 

T° dW 
aTIAgAs 


wud 
T°WIAOW 
‘1°WIAOW 
T°WIAOW 
T°WIAOW 
ore): | 

T° dWo 
IHG 
3Nad 
ad°dwWo 
T°SAOW 
7° GAOW 
WaT 
Wa 


TWIMIN 
THOWLS 


OY TMIN 
adIogd ¢s 


@dWO 


@d007 


99448899 
8887 
O8EB450DP 
8ac9 
38¢a 
9929 
387 
88r6 
78726 
BBC 
6877 
G83B98CB8P 
AI9BBEasp 
BABBEGIP 
48899800P 
gsds 


9689 
OTdbaITP 
8688L48F 


8VvB9 
B4dIGIED 


apdz 
6842 
Was9 
Tse 
8839 
asc 


Va99 
GIIIGBABOWVASY 
d4444006998¢ 
ddd I0308099F 
ddI IGG BWIOP 

99 

asa 

93929 

94448995 
ood 

98824 

apv~ 

64dd89Lb 
€808846F 


8VB08880 
9V888080 
CVBDB888 
8V808009 
36800808 
26080966 
V6000008 
86080088 
96068800 
b6908000 
768800868 
38000008 
V8988008 
98660088 
78888008 
88808080 


4L680880 
VL000808 
91886988 


018000000 
61680800 


398699088 
99988808 
V9B80800 
89080808 
99808000 
b9888800 


79680888 
25888869 
958608008 
8SBB8088 
Vb808008 
87888080 
9898080 
vPBOBB8B 
60869068 
JE080980 
9£880808 
vesoeaoe 
9€066900 
cEBBHBBB 


Bee Gd & 


SEG SSG eon oad & 


40 





ang 
YITIVS OL NUNLaY SLU 
SUSLSIOgN 3YOLSaU 9V-8V/Ld-80%+(dS) ‘T° WAOAOW 
MOWLS 3YOLSSY GNV agua hd WINN 
LUASNI YWSNIT JANILNOD .LNOdOOT’ Ba yuaa dIGNg 
A -> (T-f)934 (bv) ‘SW/La-Sad =‘1°WSAOW 
dOOT UNNILNOD (C)AIWM < (A) ARM AI NIdO0O1 IHG 
IwN03 STIHM dOO1 CAdWO‘ Td anad 
(Cf) AaN-(A) ASH BYWdWOD +(Zw) 4+ (ev) a*dwWo CAdWO 
Tq NI Y3LNNOD doo1 Td‘ T-Na TANF "1° AOW 
(c) 4a <- EW ew’ (TW) Ady W317 
(A) Adu <= Z¥ zw’ (dS) Aa vat 
T*l = Cc Tw! (TW) NATAULNG wa 
(T-f) O9u LXEN <- PY pw‘IW ‘I°SAOW 
dW3L -> (T-f)5auN (ow) ‘ba-Td ‘T°WaIAON 
(fc) Ogu => dWaL ba-10’ (tw) ‘I°WSAOW NIdOOT 
(T-f£) O99 <- PW SWIUd pw’ aw 1° SAOW 
(T#I) Ogu = (C)OqU <- Tv TW’ (QW) NATANLNG va 
aYWdWOD ABM YOd AOWLS NO ANW (dS) ‘L4G-Sd ‘I°Wa3AOW 
(I)ogu -> A SV¥/LG-SG‘ (@W) ‘T°WSAOW 
(T+I) AIM => (I)A3N aI HONWUE aIanga sia 
IWNOT ATIHM dOOT TIIdwo’ ta anaqa 
(1+1)A9N-(1) AIM TUWdWOD + (Zw) 4+ (ew) @°dwo TIIdwo 
SUVdWOD YOd YSLNNOD doo 1d‘ I-NU1AINF 1° SAOW 
(T+I)AaN <- EW EW’ (OW) ATM+NITAULNG wal 
(I)A4ay <- @W zw’ (6W) AGM wa 
I-I -> I ev’ (OW) NA TAULNG- W31 LNOdOOT 
@ HONOYHL Z-N WONd SIONWY ad aa‘zt ans 
MOWLS NO WEYW AdOD AGM wAw FLVOOTIV NFTAULNG-# / OW MNIT 
aQu0o3ayu dOL GNW LNNOD auoogsYy avoig4y OV/Ga‘+(dS) ‘I*WIAOW 
. * 
S41dO0D GuYODIU SYVdWOD ASM wAuw YOI GSANISIY SI JOWdS WOWLS ?24LON s 
+ 
YALNIOd GWVYd — OW * 
WALSIOGU JAWS wAw - SV » 
(T-f)0gu - PW SUdLSIOSY FAVS whe. - L0/S0 * 
SUY3LSIOGY WUOM - EW/ZV SUBLSIDSY dv¥MS - $G/za * 
(f)O3d - TY WaLSIO3HY d¥MS GNY YSLNNOD - Ia * 
(I)o3u - @W JOULNOD dOOT - 9G *4SN YALSIOaU » 
, * 
aSVHd LYOS NOILUASNI * 


--@ SuOuYds TWLOL 


SL4apb 
ddd Ligop 
aSap 


984d80TS 
GAB7THABH 


8379 
04ddd6099S 
86S 
987L 
€60864Lb 
€B8GIISF 
BI OB63CF 
6b8~ 
3TOSbasBy 
ATOSTIOP 


8b 87 
OTOBBAEP 
B39B8La8Y 
83B280D¥ 


ZeeE9 
0ddd699S 
@9Sd 
9BCTL 
€TSB8ILE 
€8B883Sb 
G44dd89TH 


8bSS 
839 49S90 
TOTBAGOD 


BAT BA088 
beTesoes 
COTBBBDS 


44898868 
VdI899880 


8498886008 
bdB09008 
74680880 
842008800 
23980288 
83090088 
bIBBLOBB 
TAGHB08B 
4108682800 
Vd8680808 


80680908 
vasgs8H88 
808680850 
90888008 


WO888088 
99888808 
yOB8808B 
70890088 
34808068 
Vdb080808 
996900008 


yasG0b08 
88000000 
OV8688898 


FERERE 


Bee 


eee SS eon S So fea SSOeoeds 8 & 


T9t 
89T 
6ST 
8ST 
LEST 
9ST 
SST 
yST 
est 
zst 
TST 
OST 
6bT 
8eT 
LyT 
9bT 
Sbt 
bbT 
cet 
cot 
Tet 
YT 
6€T 
BET 
cet 
SET 
Set 
vet 
cet 
cet 
TeT 
OeT 
6eT 
8cT 
Let 
92T 
SzT 
ber 
EzT 
e2T 
Tet 
8zT 
6TT 
SIT 
LTT 
OTT 
STt 
vit 
ett 
ett 


41 


16 ysnd 


xp ysad 
S43Qstbas Durysom anaes 1 re ysnd 
ease Tero] us 49d J2au Qag |! sp ysnd 
ose TeIOT Ut u 4eag ft a3 ysnd 
Prue [PIT ut w Qag 1 xq yend 
AQTLUQSSauppe yr2eAIs YStIQqeqysy ! dq ysnd 
sez soud 2405 yaTNdb 
UOFQIUNZ Y4OS 4O 9404S : 
t 
CLazfys Psor,au—dq}] uqd aghgq aba ease dway 
w 403 @aue aaeg ! eeu nba w 
uU sOg Base anaes, t @+4gd saa nba u 
330° 304 40g Base anes 1 COT+dq] 39d puom nba sgd7 sau 


' 
sdod pue seysnd yytm ' 

P2LO9GI4 PUM POITLEZSUS Bue GATgezuen perso, Guzymorpos ayy t 
t 

4us30 nba hay qsabuse] 

8 nba @zrs 2a4 psom 

' 

“pasn AT Uowwod SUOTZMTASUQQGe autszeg 


‘SHOTS 249 40g Qdar2na Quauedsuesg ave SuaqgsyGau [iy 


1q 9408 WOTZUASUT 03 QUsOd sagsuesy w 
sp SIfFUISG P4OIIU 4O YUPzS 03 “aQuiod Jaa 
a2 OOOO! => N > O S3QuUawatTs 4O saqunu u 


[SsagepGau oy UF Passed aue Suaqaweued unoy 


ee ee a ad 


UoTZIUNY 340S4HITNO 
t 


91 nba azy6 psor,au 
€ nba 908330 hay 
Z nba yqSuay hay 


Spuoras uOZg SANTOA [eRI0[ autsag t 


@po2:s2 aunsse 
.?po2, IXtTqnd quawhas apo? 


[8930p pue wYyITuOHTe NGA ayy soy 
TD yuewy2uag 3824 aweu 


32YNO0S 


OS 9S 9000 
ov 2s $000 
8b Os vooo 
Lo 

9b at €000 
Sb 1g 2000 
vp ES 4000 
Ep 6S 0000 
2p 

ly 0000 
Ov 
6E 

et 

Ze £210100- 
9€ £33000 
cE £19000 
ve £3¥v000 
€& 

Ze 

te 
o£ 

2 4300 
82 8000 
22 

92 

S2 

v2 

£2 
22 

tz 

oz 

bt 

at 

ra 

ot 

ct 

vt otoo 
Et £000 
Zt £000 
Tt 

ot 

6 

a 

Z ae 
9 

S 

v 

& 

2 

t 

ant rao 6907 


CES = 9523s SAT ESNSOM (18/2/8)298P GBe 1990W:Ts: QQuwee :Ag QZIWOANI] YS 1EGW3SSY 
= _ (80 TGL1OW-t4: NI Ga9vId 3WMGOW 193ra0 
1 WUVWHONSE JS31 JINGOW 4O ATAWASSY OCA Y3TMW3aSSY OYUIVW 8808/2808/9808 11-SISI 


HOS¥IIND 9808 123U] 
jd XIGNAddV 


42 


(tT) 20u'° w fo Cf => 3 

(02202 > CF) IO4 STEYR OnuTQuoy | doo, } 
(TU) 2a4 — ($9328 Ouedwoy 1 

hey 843 gO 3684 242 SUyweZe asa ue@en? 

doo, ¢ 

dool ft 
hay gQ aghq 384Ts 98 Yoo? |? 

A 404 3294960 3288 | 3S ‘3— 

9a5940 hay ts 

CF)IJean’ w BP dq‘sp 

toy =o eS dq 

fF so fF seyatTe Suspyoy yI2eQ8 UO peYysnd st im 3 

CT) 2ea” ip 

hay gO {[-yQhueT se 

(fy r2as° 1q 

(F)aes” dq 

$8 = 88 


(1) 308° » 88 


t= 398 

n@Q@ UT Jes ow Ff wsoy 
19307 30g 4 8Aeg 
aseqg 42848 AEG 


3 => F @> T s0g (348) 28d w> ($)284 w 


1puesay 
qf 


qsdw2 
aow 


ef 

qt 
qsdw> 
Acw 
aow 
aow 
ut 


:e6esn seqgsybey 


“@TTSQNS gO Qued 49a, sarc dyag 


> ¢§-1) 984 
woettis¢d 


up ‘se 
t-4g Bue, hey xe 


xp dq 
nq 
nq 
dq 


aq 
:@30N up 


AoW 
Aaow 


edau 


:doot 


:dooyt - 94898au 


aow 

aus 
ysnad 
yond 


:dooy 2egno 


4 
U 


:o6eEn sagstbay 


‘9408 UOTZLOSUF BYR O4OYeQ 24084IEND go doo, 403NgQ 


2408 UoTQseBUT Bunogeqg paddod eq TIIM 
42098 SABE fT °d Agdwe e,e3, pus 

(N) 384° ws 4 

(TEN) 294° mw RG 

(022045 @ Ep 

(1) 204° w KG 

(0) 3ad* Wsoyg 


Sese @aes gO aneqg Agsquepy 


=“. a wee = 


19 
secre 
mq 
12 ‘xq 
uqeup 
5q 
Gp ing 


dsdq 
se 
Pp 


ysnd 
JOR 
3ep 
ppe 
aow 
aus 
aow 


aow 
ysnd 
ysnd 


teoo 
0c£00 

00 
az0o 


8200 
6200 
8200 
9200 
€200 
1200 
0200 
0z00 


3100 
atoo 
atoo 
6100 
8100 
2100 
9too 


9100 


43 


JO2ZUTOd UOFQZEUTZSOD ga dune agny 


saquyod elunce dung 


doo, sepunadd anuzguos 


40QUzOd UOFQEUTQBBP gO dung oyny 


saquzod elunos éwng 


qf) 204° = Bp (f)284' o 88 


Fo mc F oF dune 


Psor2B4 @ YO B78 PsoM 320 


(1) 2s wo BerKp 


(F)20n° = HQ ‘6p 7Q48858y ' 
4 
edooy dems dooy 
ASOIS 
18 2uy 
38 aus 
ue'cys) Byrn 
Ctp}:se*xe acw 
:Zdooy demas 
$ 
°¢F) 204 UZIM (7) 203 SFueyrK® Qsutyg 3Ng ¢ 
‘218 93098 O42 UO BUOTZFUTPOP BLFEGns saeg ‘ 
‘ 
dooy F guegeas dwf 
tédooy deans doo, 
aso3s 
1s Dut 
16 auy 
ne ‘*C TS By 
Ctp):se'se aow 
:psooy dems 
‘ 
“CF y2oa YVEIM (4) 304 abueyrrg t 
t 
dq‘ta aow 
zdooy dems oef 
nq‘:dq dw2 
eZyS 282 puom'nd aow 
18 ‘3p aow 
$8 ‘3s 40K 


Spsor04 go eSueyrz2e w0y euedeug 


°9803 dems soy |; pue f essedwop 


iqutpP ([)204° = 88 t-3¥ we fF 


(1) 204 ¢ (f)204 @TFYRM anusgquOD 


(T)304 — (f)20a4 euedwoy 
fey 84g gO 9885 BY 38 YOOT e813 


hey aug gO egfq years 843 98 YOO 4 
A £09 3289¢0 3288 


qf )2as° =m Bp 


“(f)20n° = Spine Yderx® e4090q Be ewes Suazetbay 
"@TESQNS gO Qued Qybyu sano dyag 


doo; f 


tf ee) 


fy auedwoo 
doo, f 


¥8 ‘TP 
226ggo fay ts 
uQ ‘sp 

aq 


19 4essy 


fy esedwos 


=2 2 2 a @ 


ef 


qsdw2 edau 


6338 


B0eL 
eaac 
008064 
3368 
93CE 


£900 
9900 
6900 
¥900 
2900 
4¢S00 
4600 


agoo 


8600 
wsoo 
6600 
8c00 
9600 
€soo 
€600 


ts600 


dv0oo 
avoo 
wv00 
8v00 
9700 
900 


ev00 
€v00 
ev00 
Ovoo0 


3£00 
9€00 
gcoo 
6€00 
9£€00 
v£00 
ceo00 
€cE00 


T= 92099 ¢ ap ysnd 


Bee ees ‘Test T (a iy Bupsepso 430398 


F-4 > 1-F at dune ¢ {742898 of 
F-4 yatm I-f esedwoy 1 18'tP dw> 


‘w UBYa sebsel ese Y20Q ‘280648, BF OT FEANS YIFYR Oog 


@ => fFau gf dune t J meu 4e8 eae 

w ygte f—s esudwod 1 a> ‘t8 éu> 
wclesu go} 0g we I-f 

dooy ueqno dwf 

42038 woug { 280 |! ap dod 


‘ ocepesee ts OF Bupuepso 42099 
“42898 842 WOuy 4 pue fT 386g 


Agdwe gf 3408 uosQsesUy Og ! 403NO pues sf 
QNI@a Js 38a) 1 uqQ'ng 40 
Agdwe Gf 42898 |842 gf O95 1 sq dod 


fAgdwe g0u gf 42098 |849 wosg szed [T's QReU 329 
‘w o> SOZTS STTSANS 40g 


w¢c-s gs dwnr TY mau 388 ef 
ua¢ye dwa 
wc i-f of den 1 w 3q uf ef 
K2°$eP dw 

T-F g0 ezys aTFeqns ve 

f-3 gO O78 BT FS9NS 18 

w x2 

qf)r2au° 1e@ 

(4)2aa° nq 

(1) 2e4° sa'xp 


:eGeen 394s; bey 


ee KD wen? aow 
Gupyeseuppe 42838 |s0gsey | dq éod 
t-f ow yp f mp 'tp qns 

C = ¥p 5 ne‘tp aow 

f-4 = {es f xe ets qns 

Sm KQ'ts 6 uQ‘ys aow 

dwkQ 3240 ¢ aq dod 

f aaesg t uq‘xe aow 


if @epntruy 2OU OP BeTTAANG :820N “3408 03 aT Feqns quau eyg 
@y2 euswuszep 03 fou pue I—-f gO Batts STTggns ayy euedwo) 


aa = = 


-_—s ee a eee oe 


ete 


coe 
e202 


26 


e022 
asge 


9094 
tage 


3883 
WG 


atws 
aqgo 
aG 


Wide 
14e€ 


9024 
@j6C 


3800 
2800 


ve00 
6800 
8800 


9800 
6800 


2400 


7400 


€200 
¥i00 
2200 
0200 
3900 
2900 
8900 
6900 


45 


(3)2e8 eaeg 1 Se ‘xp aow 


¥ @aeg t nq ysnd 
P10304 @ gO 3UNOD PseERM 3a9 | altysS 2304 psom ‘se aow 
[uUmOp” eacw 
t 
‘punog sy ‘ 
(5) 20d eC P4OIOL @ TFZUN YUSWOTS duo UMOP SITEGNS B4zQUs AYA BAW ‘ 
t 
(343) 3048 > (7) 204 OL FYUM doo7 ¢ doo, 3s8e{ qf 
(los) 204 =~ (F) 204 OuBPdwoy 1 qsdw2 oedau 
fay gO 9884 euywery 1 a@eng aow 
umop eacw ef 
dno{” qee% af 
Shey go seqgha 38, euedwo) 1 qsdw> 
up 'tp aow 
2984999 UOTQEUTISEP Pus BI4NOS 3Qeg 1 up ys aow 
¥ es09Bey ¢ nq 2320p 
(34S) 304° w 88 rq‘se aow 
nq duty 
(¥)32@u° w Bp ft uq ‘ep aow 
euop eqft 
0 = § Gushtdwe (0) 204° soy 380) 1 330 304 /nq dw> 
t+ - t = | waoy 1 nq 209 
:d00, 4801 
‘ 
T+} = BQ :830N ‘ 
t 
208900 hay 908 1 2ea8gy0 hay exp aow 
yaGuez hey 30g 1 3-NQGuel hay xe aow 
:dooy gee,” uaque 
(Up2@n° wm fF BUOY ¢ 390 Jasenq ppe 
yqhuey, heusue [euz8zyuo 300 1 urna aow 
dwaq uog e20ds8 eqe20TIy ¢ OZ78 psoreu ‘ds qns 
3489Nn0 pue 
t 
“ROLLE P4OI9L B4AZQUS J2YQ UO 92408 UOFZUHSUT Ue wWaogsag t 
‘ 
doo], sagno dwf 
owes Sujewau 4 ft up auy 
tef se 1 30g ¢ x@‘Ep aocw 
777 meu 3a8 
Fm + 4298 ¢ xe ysnd 
t= f 433038 1 up yond 
fy" gaeas 
‘ 
“(@TFeqns sahsey 049) “f-s go BAzweT seddn pues seMOoT YBN, t 
‘ 
doo, 4a3n0 dwf 
owes suyewes { 1 "q 2ap 
t-Ff = J mou 388 | xe eng aow 
ia meu 308 
f =e & 92098 1 s@ ysad 


492 
992 
G92 
92 
E92 
c9z 
19¢ 
092 
6Ge 


Bcc 
L462 
962 
6e 
vce 
Ece 
ece 
tG2 
oce 
6ve 
8re 
Lve 
9ve 
Sve 
vee 
Cvz 
eve 
Tee 
Ove 
é€e 
ece 
4€2 
9E2 
Gee 
vee 
cc? 
cee 
TE? 
OF? 
622é 
Be 
Lceé 
922 
cece 
wze 
Eze 
e2z 
12e 
C0) of of 
612 
are 
Lie 
VIZ 
cle 
wte 


012368 


46 


u a4098ey 
490° 204 O40980H 


@2ue 43838 seeTD 


$ auogsay 


Am (jJ-f) 204 

yugSuet aaow 48g 

ease Aussodweg gO SSauppe 30g 
$8 :8p UT A gO SSeuppe 200 
(3-f) 202 09 988990 908 


A> ¢F)208 OTTER OnUusQue) 
SSeuppe eseq Meu 40g 


A UIte ¢(fy2e4 suedwop 
Gugsg8 auedwod go e248 988 
hey (Ff) 204 sOog 28990 Sey t8 
ease dweq gO SSasppe 309 

A’ @ 3p:se 

tberaf 


“mou 
(P)204 w (y—-f)308 
ygGuaet saow 388 


(t=) 204 404g JOBgsO BE TP 
(f)204 uog 208g90 BF 38 


nq us § seworeg 3-6 


(h)20n aw A 
QUNO2 SAC 20g 


ease dweqy 40 SSauppe 20g 


"2 dad 
Sp dod 
xe dod 
ap dad 
18 dod 
ia: dod 
se dod 
dq‘ds aow 
:euop 
t 
‘su0gs TGeu e404884 ‘aUuOpP IY ¢ 
‘ 
doot 9807 wequa dwf 
nq dod 
astaow des 
ue¢na aow 
ease dwey ys wat 
up ‘sp aow 
TP ‘TP son 
‘ 
°c pro)rzeu 03 A fdoa ¢ 
« 
doo” umop eacw qf 
RQ ‘sp aow 
nq‘°se aow 


yg8uet fag 33 
2aegso hay 38 

9084990 Reoqeease dwag ‘tp 
Kp ‘se 

¥q 


(Jef) 204 40g 388940 OF 48 


ase =a = 


qsdw2 oded 


asAaoce dea 


send aow 
tP ‘UP 408 
GZS psares 76 aow 
:d00[”~ umap aaow 
‘ 
Ssakp :Zu888y ‘ 
"(tf ) 304° = 8p = 88 88 4 
t 
nq ‘80 aow 
AsAoe dea 
gp@eenga Aoe 
ye ys 408 
waue dwey ‘tp wat 
up ‘se Aacw 


922 
Le 


€2é 


7 & a) 


B9e 


€238 
cv 

€4 
e208 
94CE 
0413208 
22939 


@aoo 
vaoo 
6a00 
4a00 
sa00 
zaao 
oa0o0 


47 


q2efeg f+ we 
Quoa” yaznd Eze 
e2ze 
28s tee a2 Etto 
dod OzE ag Z2tto 
@ es10Qsey 1 dod étc gs tito 





NOTES 














MOTOROLA SEMICONDUCTOR SALES OFFICES 


MOTOROLA SEMICONDUCTOR 
AMERICAS DISTRICT OFFICES 
ALABAMA, Huntsville ..........., (205)830-1050 
ARIZONA, Phoenix «+++ (602)244-7100 

ARIZONA, Phoenix 





(General Motors Group)........ (602)244-7125 
CALIFORNIA, Encino/ 
Sherman Oaks ......-.....00-.. (213)986-6850 


(213)872-1505 
CALIFORNIA, rach 
(Orange Exch} . 
(LA Exch}. 


.--. (714)634-2844 
oes -. {213)445-5585 
CALIFORNIA, San Diegi .. (714)560-4644 
CALIFORNIA, San Jose - (408)985-0510 
COLORADO, Colorado Springs .. (303)599-7404 








COLORADO, Denver.......... - (303)7 73-6800 
CONNECTICUT, New Haven/ 

HOMGGN -.-s.-esccesceceeses «. (203)281-0771 
FLORIDA, Pompano Beach/ 

Ft Lauderdale ...... .. (305)491-8141 
FLORIDA, Gasselberry/Maitiand (308)831-3422 
FLORIDA, St Petersburg ......... (813)576-6030 
GEORGIA, Atlanta ........ (404) 256-0222 


ILLINOIS, Chicago/Schaumburg (312)576-7800 
INDIANA, Fort Wayne .. (219}484-0436 
INDIANA, Indianapolis : 14317) 849-7060 
INDIANA, Kokomo .... «» (317)457-6634 
1OWA, Cedar Rapids .. «+ (319)373-1328 
KANSAS, Kansas City/Mi «+» (913)384-3050 
MASSACHUSETTS, Bertin ...... (617)562-3856 
MASSACHUSETTS, Burlington .. (617)273-5020 
MICHIGAN, Detroit/Westland .... (313)261-6200 
MINNESOTA, Minneapolis (612)545-0251 











MOTOROLA Semiconductor Products Inc. 


MISSOURI, St. Louis... 
NEW JERSEY, River Ecge ... 
NEW YORK, Poughkeepsie/ 


+ (314)872-7681 
+ (201)488-1200 








IRANI ces caeah eee iastesaoi es (914)473-8102 
NEW YORK, Long Isiand/ 
Hauppauge (516)231-9000 





NEW YORK, Pittsford . 
NEW YORK, Syracuse. 
NORTH CAROLINA, Raleigh 
OHIO, Cleveland 
OHIO, Dayton .. 
OHIO, Columbus, 
Worthington ...... 
OKLAHOMA, Tulsa - 
OREGON, Portland .. 
PENNSYLVANIA, Prutacelphia/ 


(716)248-5494 
{315}458-7373 
(919}876-6025 
(216}461-3160 
(§13)294-2231 


(614)846-9460 
(918)664-5227 
(503)641-3681 

















Horsham.,..... ad (215)443-9400 
TENNESSEE, Knoxville . (615)690-5592 
TEXAS, Austin (512)452-7673 





TEXAS, Dallas (214)931-9222 





TEXAS, Houston ..... .. {713)783-6400 
UTAH, Salt Lake City. ... (801)539-1190 
VIRGINIA, Charlottesville - {804})977-3691 
WASHINGTON, Bellevue . (206)454-4160 

Seattle Access ........ « (206)622-9960 


WASHINGTON, DC/MARYLAND, 





Hyattsville . (301)577-2600 
WISCONSIN, Mi waukee/ 
Wauwatosa ... (414)476-5554 





Field Applications Engineering Available Through 
All Sales Offices 


MOTOROLA SEMICONDUCTOR CANADA 


MANITOBA, Winnipeg ...... » (204)889-0693 
ONTARIO, Bownsview/Toronto . «. (416)661-6400 
ONTARIO, Ottawa .... » (613)235-4388 
QUEBEC, Montreal : <. (514)731-6881 
MOTOROLA SEMICONDUCTOR 


INTRA-COMPANY OFFICES 
ARIZONA, Scottsdale ............ (602)949-3811 
FLORIDA, Ft Lauderdale «+» (305}475-6120 
ILLINOIS, Franklin Park’ 

«+ (312)576-2788 


Schaumburg 
ILLINOIS, Schaumburg » (312)576-5518 
(312)576-7800 


ILLINOIS, Schaumburg’ 
Baoan, (817)232-6255 


Automotive ....... 
TEXAS, Ft Worth . 

MOTOROLA SEMICONDUCTOR 
INTERNATIONAL SALES OFFICES 

















AUSTRALIA, Melbourne ......... (03)561-3555 
AUSTAALIA, Sydney... 438-1955 
439-2242 


AUSTRIA, Vienna . 
BRAZIL, Sao Paulo 
DENMARK, Gladsaxeve) 
ENGLAND. Wembley. Middlesex 
FRANCE, Grenoble -. ‘ 

FRANCE, Paris 









(01 ie a 22 
-- 01-902-8836 
- (076)90 22 81 
-(01)555-91-01 





FRANCE, Toulouse ae vs. (061)49 41 8B 
GERMANY, aramohagen 
Hannover .... =. (0511)78-20-37 








GERMANY, Munich ................. (089)92 481 
GERMANY, Nurenberg .. +++ + (0911)65761 
GERMANY, Singeltingen - (0703183074 





GERMANY, Wiesbaden . 


» (06121)76-1921 
HONG KONG, Hung Hom. 














Kowloon ...... veveesese ++ 9-632201-8 
3-336211-22 

ISRAEL, Tel Aviv .. 
ITALY, Bologna . 
ITALY, Milar. . 
ITALY, Rome ... .- (03)831 4746 
JAPAN, Osaka -(06)305 1421 
JAPAN, Tokyo » + 038-440-3311 
KOREA, Seoul .. seeeey, 261-7137 
MEXICO. DF... * (625)524-0706 
NETHERLANDS Utrecht -{030)443 808 
NORWAY, Osio........ oo... (02)671467 
SCOTLAND, East Kilbri ~ (03552)39 191 
SINGAPORE .......... . 2945438 








786 1184 
1}279 0802 
. 08/82 02 95 
+ -(022)991 411 
» (01}730 40 74 

«+ 752B944-9 


SOUTH AFRICA. Bramley 
SPAIN, Madrid . 

SWEDEN, Soina. 
SWITZERLAND, Geneva . 
SWITZERLAND, Zurich 
TAIWAN, Taipe: 


P.O. BOX 20912 @ PHOENIX, ARIZONA 85036 ¢ A SUBSIDIARY OF MOTOROLA INC. 


16718-7| PRINTED IN USA 12-83 IMPERIAL LITHO C18479 60,000 








